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Dear Sir: 



Appeal Brief 

Appellant has appealed to the Board of Patent Appeals and Interferences (the 
"Board") from the decision of the Examiner mailed January 1 8, 2007 (the "Final Office 
Action"), finally rejecting all pending Claims 1-26. Appellant filed a Notice of Appeal, with 
the statutory fee of $500.00, on April 18, 2007. Appellant respectfully submits this Appeal 
Brief with the statutory fee of $500.00. 
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Real Party in Interest 

Appellant believes this Application is subject to assignment from the inventor to 
Cisco Technology, Inc. 
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Related Appeals and Interferences 

Appellant previously appealed examination of the present Application to the Board 
through the filing of an appeal brief on January 22, 2004. That appeal was assigned Appeal 
No. 20005-0521. The Board affirmed in-part and overturned in-part the rejections then 
pending in a decision issued on May 24, 2005. A Request for Rehearing was denied on 
September 15, 2005. Copies of the Board's decision on the appeal and the rehearing are 
attached as Appendix D. 
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Status of Claims 

Claims 1-26 are pending in this Application. Claims 1-26 stand rejected pursuant to 
the Final Office Action, and are all presented for appeal. All pending claims are shown in 
Appendix A, along with an indication of the status of those claims. 
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Status of Amendments 

All amendments submitted by Appellant have been entered by the Examiner prior to 
the mailing of Final Office Action. 
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Summary of Claimed Subject Matter 

This invention relates in general to data communication, and more particularly to a 
system for communicating management information (Page 1, Lines 2-4). 1 

Network devices are generally arranged in a chassis or housing at a particular location 
in a communication system. Each network device arranged in a particular chassis may be 
configured, initialized, or otherwise managed using consoles external to the chassis. A 
drawback to prior systems is that each network device in a chassis requires a corresponding, 
dedicated console to handle the management operations of the associated network device. A 
further drawback is that the interface card of each network device in the chassis must 
maintain a dedicated connection to its corresponding console. Such a configuration of 
consoles and network devices adds costs and complexities to the management operations of 
communication systems. (Page 2, Lines 2-14). 

Thus, the present Application discloses a management system 10 that includes a 
management card 12 coupled to a number of interface cards 14 using links 16 and coupled to a 
client 18 using a link 20. In general, client 18 handles the primary management responsibilities 
for each of interface cards 14 and/or associated network devices 24 using management card 12. 
(Page 6, Lines 2-8). 

Management card comprises any suitable combination of hardware and software 
components that establish one or more communication links 22 between client 1 8 and one or 
more interface cards 14 selected in response to a command 40, and communicate management 
information 42 to the interface cards 14 using communication links 22. Although management 
card 12 is illustrated separate from interface cards 14, it should be understood that management 
card 12 may be formed integral to or separate from a particular interface card 14. Management 
card 12 is described in greater detail with respect to FIGURE 2. (Page 6, Lines 9-19). 

Management card 12 may establish and maintain communication links 22 between a 
client 18 and any number and combination of interface cards 14. A communication link 22 
comprises any switched communication path that couples client 18 to an interface card 14 
and communicates management information 42 using any suitable communication protocols, 
standards, and/or formats. (Page 6, Lines 23-30). 

Each interface card 14 comprises any suitable combination of hardware and software 
components that enable network devices 24 to communicate with various components of a 

1 All citations in this section of the Appeal Brief are to Appellant's originally-filed Specification. 
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communication network (not explicitly shown) and with other components of system 10. For 
example, interface cards 14 include management ports 26 that couple network devices 24 to 
management card 12 using links 16 such that devices 24 may communicate with management 
card 12. Network devices 24 comprise computers, servers, workstations, IP telephones, 
routers, bridges, switches, gateways, hubs, and any other suitable electronic devices that may 
be managed by client 18 using management card 12. (Page 7, Lines 14-25). 

In operation, a user operates client 1 8 to communicate a command 40 and management 
information 42 to management card 12. Management card 12 receives command 40 
communicated by client 1 8 and establishes one or more communication links 22 between client 
18 and particular interface cards 14 selected in response to command 40. Using 
communication links 22, management card 12 communicates to the particular interface cards 
14, the management information 42 communicated by client 18. (Page 8, Lines 18-26). 

FIGURE 2 illustrates management card 12 in more detail. Communication link 20 
couples client 18 to interface 50. Interface 50 couples to a line driver 52, which in turn 
couples to a processor 54. Processor 54 manages the overall operation of management card 
12 and couples to memory 56 and line driver 58. Line driver 58 couples to switch 60 at a 
first port 62. Links 16 couple to switch 50 at second ports 64. (Page 9, Lines 3-10). 

Processor 54 comprises a central processing unit having any suitable general purpose 
data processing capabilities. Memory 56 comprises any suitable volatile or non-volatile 
memory device associated with processor 54. Memory 56 generally stores a number of files, 
lists, tables, or any other arrangement of information that support establishing communication 
links 22 and communicating management information 42 using communication links 22. For 
example, memory 56 stores program instructions 70 and a mapping table 72. Information 
maintained in memory 56 may reside in different components of management card 12 or in 
components external to management card 12. (Page 9, Line 28 - Page 10, Line 4). 

Switch 60 comprises any suitable combination of hardware and software components 
that establish communication links 22 between clients 18 and particular interface cards 14 to 
direct, couple, or otherwise switch management information 42 communicated by client 18 to 
the appropriate interface cards 14. Switch 60 generally comprises a first port 62 coupled to 
client 18 and second ports 64 coupled to interface cards 14 using links 16. As described with 
respect to FIGURE 3, memory 56 stores a mapping table 72 associating particular interface 
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cards 14 and/or network devices 24 to particular ports 64 to support establishing 
communication links 22. (Page 10, Lines 22-34). 

FIGURE 3 illustrates the contents of mapping table 72 stored in memory 56 of 
management card 12. Each entry of mapping table 72 includes mapping information, such as 
a device identifier 80, an operating system identifier 82, and a port identifier 84. Device 
identifier 80 comprises information identifying a particular network device 24 and/or an 
associated interface card 14. Operating system identifier 82 comprises information 
identifying the operating system, if any, associated with a corresponding network device 24. 
Port identifier 84 comprises information identifying a port 64 of switch 60 associated with a 
corresponding network device 24 and/or interface card 14. (Page 10, Line 34 - Page 11, Line 
10). 

In operation, processor 54 of management card 12 executes program 70 to support the 
communication of management information 42 to one or more interface cards 14. In one 
embodiment, processor 54 executes program 70 to support generating a command 40 and 
management information 42 at client 18. Interface 50 of management card 12 receives a 
command 40 communicated by client 18. Command 40 generally identifies one or more 
interface cards 14 to which management information 42 is directed and is generally 
communicated using a communication format associated with link 20. Line driver 52 
converts command 40 from the communication format associated with link 20 to a 
communication format associated with processor 54. (Page 11, Lines 1 1-23). 

Processor 54 receives command 40 identifying one or more particular interface cards 
14 and determines the appropriate ports 64 of switch 60 associated with the particular 
interface cards 14 using the information stored in mapping table 72. In a particular 
embodiment, processor 54 also uses the information stored in mapping table 72 to configure 
management information 42 according to the operating systems of the network devices 24 
associated with the particular interface cards 14 identified in command 40. (Page 11, Lines 
24-32). 

Processor 54 commands switch 60 to establish communication links 22 between client 
18 and the determined ports 64 using line driver 58. Line driver 58 converts management 
information 42 to a communication format associated with links 16, interface cards 14, and/or 
network devices 24. Switch 60 establishes one or more communication links 22 between the 
appropriate ports 62 and 64 to couple client 18 to the appropriate interface cards 14. 
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Management card 12 communicates management information 42 using communication link 
22. In particular, management card 12 may communicate management information 42 from 
client 18 to interface cards 14 and/or may communicate management information 42 from 
interface cards 14 to client 18 such as, for example, in response to a request. (Page 11, Line 
33 -Page 12, Line 10). 



With regard to the independent claims currently under Appeal, Appellant provides the 
following concise explanation of the subject matter recited in the claim elements. For 
brevity, Appellant does not necessarily identify every portion of the Specification and 
drawings relevant to the recited claim elements. Additionally, this explanation should not be 
used to limit Appellant's claims but is intended to assist the Board in considering the Appeal 
of this Application. 



For example, independent Claim 1 recites the following: 

A system for communicating management information, comprising: 

a first interface card (e.g., Figure 1; Page 8, Lines 15-27; Page 9, Lines 
28-30; Page 9, Lines 16-22; Page 14, Lines 28-34); 

a second interface card (e.g., Figure 1; Page 8, Lines 15-27; Page 9, 
Lines 28-30; Page 9, Lines 16-22; Page 14, Lines 28-34); and 

a management card coupled to the first interface card and the second 
interface card (e.g., Figure 1; Page 7, Lines 8-19; Figure 2; Page 10, Line 9 - 
Page 12, Line 6; Figure 3; Page 12, Line 7 - Page 14; Line 2) the management 

card operable to: 

receive a command from a client, the command identifying an 
interface card or a network device associated with an interface card; 
(e.g., Figure 1; Page 7, Line 31 - Page 8, Line 3; Page 9, Lines 22-27; 
Page 10, Lines 30-34; Page 12, Lines 20 - Page 13, Line 7; Figure 4; 
Page 14, Lines 3-15); 

establish a communication link between the client and a 
particular one of the first interface card and the second interface card 
selected in response to the command communicated by the client, 
wherein the communication link forms a complete path that couples at 
least the client to at least the particular interface card (e.g., Figure 1; 
Page 7, Lines 20-30; Page 7, Line 28 - Page 9, Line 3; Page 9, Lines 
24-27; Figure 2; Page 10, Lines 10-11; Page 11, Line 30 - Page 12, 
Line 6; Page 12, Line 34 - Page 13, Line 16; Figure 4, Lines 16-20); 
and 

communicate management information using the 
communication link (e.g., Figure 1; Page 8, Lines 4-14; Page 9, Line 
28 - Page 10, Line 8; Page 11, Lines 3-7; Page 11; Line 30 - Page 12; 
Line 2; Page 13, Lines 8-22; Figure 4; Page 14, Lines 20-34). 
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As another example, independent Claim 7 recites the following: 

A method for communicating management information performed by a 
management card, comprising: 

receiving a command from a client, the command identifying a 
particular one of a first interface card and a second interface card (e.g., Figure 
1; Page 7, Line 31 - Page 8, Line 3; Page 9, Lines 22-27; Page 10, Lines 30- 
34; Page 12, Lines 20 - Page 13, Line 7; Figure 4; Page 14, Lines 3-15); 

establishing a communication link between the client and the particular 
interface card in response to receiving the command, wherein the 
communication link forms a complete path that couples at least the client to at 
least the particular interface card (e.g., Figure 1; Page 7, Lines 20-30; Page 7, 
Line 28 - Page 9, Line 3; Page 9, Lines 24-27; Figure 2; Page 10, Lines 10-11; 
Page 11, Line 30 - Page 12, Line 6; Page 12, Line 34 - Page 13, Line 16; 
Figure 4, Lines 16-20); and 

communicating management information using the communication 
link (e.g., Figure 1; Page 8, Lines 4-14; Page 9, Line 28 - Page 10, Line 8; 
Page 11, Lines 3-7; Page 11; Line 30 - Page 12; Line 2; Page 13, Lines 8-22; 
Figure 4; Page 14, Lines 20-34). 

The citations listed above with respect to independent Claim 7 are also applicable to 
independent Claim 21, which is directed to a system. 

As yet another example, independent Claim 14 recites: 
A management card, comprising: 

a switch coupled to a first interface card and a second interface card 
(Figure 2; Page 10, Lines 14-16; Page 11, Line 30 - Page 12, Line 6); and 

a processor coupled to the switch (Figure 2; Page 10, Lines 9-16; Page 
10, Line 35 - Page 1, Line 1) and operable to: 

receive a command communicated by a client, the command 
identifying a particular one of the first interface card and the second 
interface card (e.g., Figure 1; Page 7, Line 31 - Page 8, Line 3; Page 9, 
Lines 22-27; Page 10, Lines 30-34; Page 12, Lines 20 - Page 13, Line 
7; Figure 4; Page 14, Lines 3-15); and 

command the switch to establish a communication link between 
the client and the particular interface card, wherein the communication 
link forms a complete path that couples at least the client to at least the 
particular interface card (e.g., Figure 1; Page 7, Lines 20-30; Page 7, 
Line 28 - Page 9, Line 3; Page 9, Lines 24-27; Figure 2; Page 10, Lines 
10-11; Page 11, Line 30 - Page 12, Line 6; Page 12, Line 34 - Page 13, 
Line 16; Figure 4, Lines 16-20). 
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As yet another example, independent Claim 22 recites: 

A system for communicating management information, comprising: 
a first interface card coupled to a first network device (e.g., Figure 1 ; 
Page 8, Lines 15-27; Page 9, Lines 28-30; Page 9, Lines 16-22; Page 14, Lines 
28-34) that uses a first operating system (Figure 3; Page 12, Lines 7-15; Page 
12, Line 34 - Page 13, Line 7; Page 13, Line 23 - Page 14, Line 2; Page 14, 
Lines 16-34); 

a second interface card coupled to a second network device (e.g., 
Figure 1; Page 8, Lines 15-27; Page 9, Lines 28-30; Page 9, Lines 16-22; Page 
14, Lines 28-34) that uses a second operating system (Figure 3; Page 12, Lines 
7-15; Page 12, Line 34 - Page 13, Line 7; Page 13, Line 23 - Page 14, Line 2; 
Page 14, Lines 16-34); and 

a management card coupled to the first interface card and the second 
interface card (e.g., Figure 1; Page 7, Lines 8-19; Figure 2; Page 10, Line 9 - 
Page 12, Line 6; Figure 3; Page 12, Line 7 - Page 14; Line 2), the management 

card operable to: 

receive a command from a client, the command identifying an 
interface card or a network device associated with an interface card 
(e.g., Figure 1; Page 7, Line 31 - Page 8, Line 3; Page 9, Lines 22-27; 
Page 10, Lines 30-34; Page 12, Lines 20 - Page 13, Line 7; Figure 4; 

Page 14, Lines 3-15); 

establish a communication link between the client and a 
particular one of the first interface card and the second interface card 
selected in response to the command communicated by the client (e.g., 
Figure 1; Page 7, Lines 20-30; Page 7, Line 28 - Page 9, Line 3; Page 
9, Lines 24-27; Figure 2; Page 10, Lines 10-11; Page 11, Line 30 - 
Page 12, Line 6; Page 12, Line 34 - Page 13, Line 16; Figure 4, Lines 
16-20); 

configure management information for the operating system of 
the network device associated with the particular interface card (e.g., 
Figure 1 ; Page 13, Lines 2-7; Figure 4; Page 14; and 

communicate the management information using the 
communication link (e.g., Figure 1; Page 8, Lines 4-14; Page 9, Line 
28 - Page 10, Line 8; Page 11, Lines 3-7; Page 11; Line 30 - Page 12; 
Line 2; Page 13, Lines 8-22; Figure 4; Page 14, Lines 20-34). 
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Grounds of Rejection to be Reviewed on Appeal 

1. Do Claims 1, 7, 14, and 21 comply with 35 U.S.C. § 1 12, first paragraph? 

2. Are Claims 1, 4-7, 10-14, 16, 18-22, and 24-26 patentable under 35 U.S.C. § 102(e) 
over U.S. Patent No. 4,937,777 issued to Flood et al ("F/ood")? 

3. Are Claims 2-3, 8-9, 15, 17, and 23 patentable under 35 U.S.C. § 103(a) over Flood 
in view of U.S. Patent No. 6,304,895 issued to Schneider et al. ("Schneider")? 
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Argument 

The rejection of Claims 1, 7, 14, and 21 under 35 U.S.C. § 112, first paragraph, is 
improper and should be reversed by the Board. The rejection of Claims 1, 4-7, 10-14, 16, 18- 
22, and 24-26 as patentable under 35 U.S.C. § 102(e) over Flood is improper and should be 
reversed by the Board. The rejection of Claims 2-3, 8-9, 15, 17, and 23 under 35 U.S.C. § 
103(a) as unpatentable over Flood in view of Schneider is improper and should be reversed 
by the Board. 

I. The Prosecution of this Application 

Appellant first comments on the prosecution of this Application. Appellant 
previously appealed similar rejections by the Examiner of Claims 1-21. In a decision issued 
by the Board on May 24, 2005 (the "First Appeal Decision"), the Board affirmed in-part and 
overturned in-part the Examiner's rejections of Claims 1-21. In particular, the Board upheld 
the Examiner's rejection of Claims 1, 2, 4-8, 10-16, and 18-21 and overturned the Examiner's 
rejection of Claims 3, 9, and 17. 

In response to the First Appeal Decision, the Appellant filed a Request for Rehearing 
on July 22, 2005 in which Appellant noted that Flood failed to disclose any "communication 
link" between the terminal of Flood and the processing module. In response to the Request 
for Rehearing the Board issued another decision (the "Rehearing Decision") in which the 
Board took issue with the Appellant's argument noting that "appellant's argument is 
apparently based on appellant's view that a 'communication link' requires that that the 
complete path from terminal... to processor... must exist at the same time." Rehearing 
Decision, Page 2. The Board continued by noting, "[w]hether the examiner and the Board 
properly interpreted the term 'communication link' is a question of fact which should have 
been argued before the examiner and should be part of the record we are now reviewing." 
Id, , Page 3. 

In response to the Rehearing Decision, Appellant filed a Request for Continued 
Examination on November 15, 2005 (the "Request for Continued Examination"), in which 
Appellant amended Claims 1, 7, 14, and 21 to more clearly convey the definition of 
"communication link" as used in the rejected claims. Additionally, Appellant added new 
Claims 22-26 that incorporated elements of Claim 3 that the Board indicated were not found 
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in the cited references. Despite these amendments and added claims, the Examiner rejected 
Claims 1-21 in an Office Action issued March 8, 2006 (the ''March 8 Office Action"). In the 
March 8 Office Action, the Examiner essentially repeated the same arguments that Examiner 
had presented on appeal without addressing the newly added limitations and ignoring the 
Board's direct indication that, at the very least, Claims 3, 9, and 17 were allowable (see, e.g., 
March 8 Office Action, Page 7). Moreover, the Examiner completely failed to acknowledge 
the addition of new Claims 22-26, providing no indication as to their status or to whether they 
were even pending (see, e.g., the March 8 Office Action, Page 1). 

Appellant filed a response to the March 8 Office Action on June 8, 2006 (the "June 8 
Response") in which Appellant noted deficiencies in the Examiner's rejections, citing the 
First Appeal Decision where appropriate. Additionally, Appellant noted the fact that the 
Examiner had entirely ignored the newly-added Claims 22-26. Appellant requested 
reconsideration and allowance of all claims. 

Appellant and the Examiner exchanged additional correspondence, culminating in the 
Examiner's issuance of the Final Office Action. In the Final Office Action, the Examiner 
again repeated the same arguments the Examiner had presented prior to the First Appeal 
Decision and prior to the amendment of Claims 1,7, 14, and 21. Additionally, the Examiner 
rejected new Claims 22 and many of its dependents on the same grounds as Claim 1, ignoring 
the clear differences between the scope of the relevant claims. Final Office Action, Pages 2- 
3. 

Thus, the Examiner has repeatedly failed to address the substance of Appellant's 
arguments. Appellant respectfully notes that the Examiner has failed to satisfy M.P.E.P. 
§ 707.07(f) which requires "[w]here the applicant traverses any rejection, the examiner 
should, if he or she repeats the rejection, take note of the applicant's argument and answer the 
substance of it " (emphasis added). Moreover, the Examiner has also failed to properly 
distinguish and consider the individual elements of each claim, instead rejecting claims, such 
as Claims 22 and 24-26, based on the wording of other claims in the present Application, 
contrary to the principle that "[a]ll words in a claim must be considered in judging the 
patentability of that claim against the prior art." In re Wilson, 424 F.2d 1382, 165 U.S.P.Q. 
494, 496 (C.C.P.A. 1970). 



ATTORNEY DOCKET NO. 
062891.0320 



15 



PATENT APPLICATION 
SERIAL NO. 09/436,920 



II. Grouping of Claims 

Appellant has made an effort to group claims to reduce the burden on the Board, as 
contemplated by 37 C.F.R. § 41.37(c)(l)(vii). Where appropriate, Appellant presents 
arguments as to why particular claims subject to a ground of rejection are separately 
patentable from other claims subject to the same ground of rejection. To reduce the number 
of groups and thereby reduce the burden on the Board, Appellant does not argue individually 
every claim that recites patentable distinctions over the references cited by the Examiner, 
particularly in light of the clear allowability of Appellant's independent claims. The claims 
of each group provided below may be deemed to stand or fall together for purposes of this 
Appeal. 

Appellant has concluded that the claims may be grouped together as follows: 

With regard to the grounds of rejection identified as issue 1 above, the claims subject 
to those grounds of rejection may be grouped together as follows for purposes of this Appeal: 

1. Group 1 may include Claims 1,7, 14, and 21. 

With regard to the ground of rejection identified as issue 2 above, the claims subject 
to that ground of rejection maybe grouped together as follows for purposes of this Appeal: 

2. Group 2 may include Claims 1, 4-7, 10-14, 16, 18-21 

3. Group 3 may include Claims 22 and 24-26. 

With regard to the ground of rejection identified as issue 3 above, the claims subject 
to that ground of rejection may be grouped together as follows for purposes of this Appeal: 

4. Group 4 may include Claims 2, 8, and 15. 

5. Group 5 may include Claims 3, 9, 17, and 23. 
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III. Issue I - Claims 1, 7, 14, and 21 Comply with 35 U.S.C. 8 112, First Paragraph 

A. Overview 

The Examiner rejects Claims 1, 7, 14, and 21 under 35 U.S.C. § 112, first paragraph, 
because, according to the Examiner, "[these] claims contain subject matter as disclosed, 
'wherein the communication link forms a complete path that couples at least the client to at 
least the particular interface card; and communication management information using the 
communication link' which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventor(s), at the time the 
application was filed, had possession of the claimed invention." Final Office Action, Page 2. 

B. Standard 

"A description as filed is presumed to be adequate, unless or until sufficient evidence 
or reasoning to the contrary has been presented by the examiner to rebut the presumption." 
See, e.g., In re Marzocchi, 439 F.2d 220, 224, 169 USPQ 367, 370 (CCPA 1971); M.P.E.P. 
§ 2163.04. "The examiner, therefore, must have a reasonable basis to challenge the adequacy 
of the written description." M.P.E.P. § 2163.04 "The examiner has the initial burden of 
presenting by a preponderance of evidence why a person skilled in the art would not 
recognize in an applicant's disclosure a description of the invention defined by the claims." 
In re Wertheim, 541 F.2d 257, 263, 191 USPQ 90, 97 (CCPA 1976); M.P.E.P. § 2163.04. "In 
rejecting a claim, the examiner must set forth express findings of fact which support the lack 
of written description conclusion...." Id. "These findings should: (A) [i]dentify the claim 
limitation at issue; and (B) [establish a prima facie case by providing reasons why a person 
skilled in the art at the time the application was filed would not have recognized that the 
inventor was in possession of the invention as claimed in view of the disclosure of the 

application as filed." Id. 

"An applicant shows possession of the claimed invention by describing the claimed 
invention with all of its limitations using such descriptive means as words, structures, figures, 
diagrams, and formulas that fully set forth the claimed invention." Lockwood v. American 
Airlines, Inc., 107 F.3d 1565, 1572, 41 USPQ2d 1961, 1966 (Fed. Cir. 1997); M.P.E.P. 
§ 2163.02. "Possession may be shown in a variety of ways including description of an actual 
reduction to practice, or by showing that the invention was 'ready for patenting 5 such as by 
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the disclosure of drawings or structural chemical formulas that show that the invention was 
complete, or by describing distinguishing identifying characteristics sufficient to show that 
the applicant was in possession of the claimed invention." See, e.g., Pfaff v. Wells Elecs., 
Inc., 525 U.S. 55, 68, 119 S.Ct. 304, 312, 48 USPQ2d 1641, 1647 (1998); Regents of the 
University of California v. Eli Lilly, 119 F.3d 1559, 1568, 43 USPQ2d 1398, 1406 (Fed. Cir. 
1997); Amgen, Inc. v. Chugai Pharmaceutical 927 F.2d 1200, 1206, 18 USPQ2d 1016, 1021 
(Fed. Cir. 1991) (one must define a compound by 'whatever characteristics sufficiently 
distinguish it 5 ); M.P.E.P. § 2163.02. 

C. The rejection of Group 1 (Claims 1, 7, 14, and 21) under 35 U.S.C. § 112, 
first paragraph is improper 

Claims 1, 7, 14, and 21 stand rejected under 35 U.S.C. § 112, first paragraph. 
Appellant respectfully submits that the rejection of Claims 1, 7, 14, and 21 under 35 U.S.C. 
§112, first paragraph, is improper for at least several reasons. 

First, to maintain a rejection under 35 U.S.C. § 112, first paragraph, an Examiner 

must "[establish a prima facie case by providing reasons why a person skilled in the art at 

the time the application was filed would not have recognized that the inventor was in 

possession of the invention as claimed in view of the disclosure of the application as filed." 

Appellant respectfully notes that, here, the Examiner has concluded without explanation that: 

[These] claim(s) contains subject matter as disclosed, 'wherein the 
communication link forms a complete path that couples at least the client to at 
least the particular interface card; and communication management 
information using the communication link' which was not described in the 
specification in such a way as to reasonably convey to one skilled in the 
relevant art that the inventor(s), at the time the application was filed, had 
possession of the claimed invention 
Final Office Action, Page 2. 

Because the Examiner fails to provide a prima facie case for rejection under 35 U.S.C. 
§ 112, first paragraph, the Examiner fails to satisfy the Examiner's burden for rejecting 
Claims 1, 7, 14, and 21 on written description grounds. M.P.E.P. § 2163.04. 

Second, the Application as originally filed does describe the relevant limitations in 
such a way as to reasonably convey to one skilled in the relevant art that the inventor, at the 
time the application was filed, had possession of the claimed invention. As noted above, 
"[possession may be shown in a variety of ways including description of an actual reduction 
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to practice, or by showing that the invention was "ready for patenting 5 such as by the 

disclosure of drawings or structural chemical formulas that show that the invention was 

complete, or by describing distinguishing identifying characteristics sufficient to show that 

the applicant was in possession of the claimed invention. M.P.E.P. § 2163.02 (emphasis 

added); see also, e.g., Pfaff, 525 U.S. at 68, 119 S.Ct at 312, 48 USPQ2d at 1647. 

For example, the present Application clearly indicates that "a communication link 22 

comprises any switched communication path that couples client 18 to an interface card 14 

and communicates management information using any suitable communication protocols, 

standards, and/or formats." Page 9, Lines 24-27 (emphasis added). The present Application 

also notes, with respect to the flowchart of FIGURE 4, that: 

At step 108, switch 60 of management card 12 establishes one or more 
communication links 22 between port 62 and the ports 64 determined at step 
106. In this respect, switch 60 couples client 18 to the appropriate interface 
cards 14 and/or network devices 24. 

Page 14, Lines 16-20. 

Additionally, FIGURE 1 clearly illustrates a particular embodiment of management 
system 10 in which communication link 22 "forms a complete path that couples at least the 
client to at least [a] particular interface card" as recited by Claim 1. In particular FIGURE 1, 
illustrates a path completed between client 18 and the interface card 14 on the far left side of 
FIGURE 1. The specific language of Claims 7, 14, and 21 are similarly supported by the 
present Application as originally filed. 

As a result, the Examiner fails to present a prima facie case for rejection under 35 
U.S.C. § 112, first paragraph. Additionally, the present Application clearly supports the 
relevant limitations. Claims 1, 7, 14, and 21 are thus allowable for at least these reasons. 
Appellant respectfully requests reconsideration and allowance of Claims 1,7, 14, and 21. 

IV. Issue II - Claims 1, 4-7, 10-14, 16, 18-22, and 24-26 are patentable over Flood 

Claims 1, 4-7, 10-14, 16, 18-22, and 24-26 stand rejected under 35 U.S.C. § 102(e) as 
being unpatentable over Flood. Appellant respectfully submits that Flood fails to support the 
anticipation rejections of these claims. Appellant respectfully submits that these rejections 
are therefore improper and should be reversed by the Board. 
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A, Standard for Demonstrating a Prima Facie Case of Anticipation 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." Verdegaal 
Bros. v. Union Oil Co. of California, 2 U.S.P.Q.2d 1051, 1053 (Fed. Cir. 1987); M.P.E.P. § 
2131. In addition, "[t]he identical invention must be shown in as complete detail as 
contained in the . . . claim." M.P.E.P. § 2131 citing Richardson v. Suzuki Motor Co., 868 F.2d 
1226, 1236, 9 U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989). Furthermore, "[t]he elements must be 
arranged as required by the claim." In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 (Fed. Cir. 
1990); M.P.E.P. § 2131. 

B. The rejection of Group 2 (Claims 1, 4-7, 10-14, 16, and 18-21) under 35 
U.S.C. § 102(e) is improper 

Claims 1, 4-7, 10-14, 16, and 18-21 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by Flood. Appellant respectfully submits that these claims are clearly patentable 
over Flood. Appellant respectfully submits that these rejections are therefore improper and 
should be reversed by the Board. 

Independent Claim 1, which Appellant discusses as an example, recites: 

A system for communicating management information, comprising: 

a first interface card; 

a second interface card; and 

a management card coupled to the first interface card and the second 
interface card, the management card operable to: 

receive a command from a client, the command identifying an 
interface card or a network device associated with an interface card; 

establish a communication link between the client and a 
particular one of the first interface card and the second interface card 
selected in response to the command communicated by the client, 
wherein the communication link forms a complete path that couples at 
least the client to at least the particular interface card; and 

communicate management information using the 
communication link. 

Flood fails to recite, expressly or inherently, every limitation of Claim 1. At a 
minimum, Flood fails to disclose "a management card... operable to ... establish a 
communication link between [a] client and a particular one of [a] first interface card and [a] 
second interface card..., wherein the communication link forms a complete path that couples 
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at least the client to at least the particular interface card " (emphasis added) as required by 
Claim 1. 

As Appellant has previously noted, the Examiner has not addressed this limitation 
Claim 1 substantively with respect to any art at any point during examination. Moreover, 
Flood explicitly precludes the inclusion of such a limitation in the system of Flood. 
Appellant respectfully notes that the Examiner has repeatedly failed to address the substance 
of this argument as required by M.P.E.P. § 707.07(f). 

More specifically, in denying the Appellant's request for a rehearing, the Board of 
Appeals indicated that: 

[Appellant's argument is apparently based on appellant's view that a 
"communication link" requires that the complete path from terminal 24 to 
processors 1 8 must exist at the same time. 

We note that the appellant's arguments with respect to this feature of the 
claimed invention in the briefs were based on whether there was a connection 
between terminal 24 and processor 18. We essentially found that terminal 24 
was connected to processors 18. We now find that the fact that data in Flood is 
sent from terminal 24 to processors 18 is sufficient to meet the broadest 
reasonable interpretation of the term "communication link." 

Response to Rehearing Request, Page 2. 

In response, Appellant amended Claim 1 to clarify the meaning of the term 
"communication link" in Claim 1. As currently amended, Claim 1 discloses "[a] management 
card operable to . . . establish a communication link . . . fthatJ forms a complete path that 
couples at least the client to at least the particular interface card ' (emphasis and underlining 
added). With this amendment, the mere fact that data could be communicated from terminal 24 
to processor 18 in Flood is not sufficient grounds for a rejection of amended Claim 1. 
Consequently, as reasonably inferred from the Board's discussion, Flood does not disclose 
every element of Claim 1 as presently amended. 

As Figure 3 of Flood and the corresponding text clearly indicate, to whatever extent 
information is communicated between terminal 24 and execution processors 18, the 
programmable controller 10 of Flood never "establishes] a communication link . . . [that] 
forms a complete path " that couples terminal 24 to execution processors 1 8 as required by 
amended Claim 1 . This is because at no point in time does the system of Flood establish all 
portions of a "communication link" so as to form a "complete path." While particular 
portions of a possible path may exist at a particular time, the remaining portions of the path 
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will not exist at that same particular time. As a result, a "complete path" is never formed 
coupling the client and one of the interface cards. 

In particular, the system disclosed by Flood includes a terminal 24 that couples to 
communication buses 21-23 through line driver 52 and 54 and serial input/output controller 
(SIO) 48. Column 7, lines 1 1-16. The Flood system additionally includes a RAM 38 that is 
also located on communication buses 31-33 and that is "for temporary storage of data 
received from or to be sent to the various external devices connected to the system 
controller". Furthermore, "[a direct memory access (DMA)] circuit 42 allows the SIO 48 to 
access RAM 38 to store or obtain data which have been received or will be transmitted over 
their respective external communication channels." Column 7, lines 31-35. Thus, data 
communicated to system controller 10 by terminal 24 is first transmitted to RAM 38 over 
communication buses 31-33. 

Significantly, however, to whatever extent execution processors 1 8 may subsequently 

have direct access to RAM 38, they are not able to access communication buses 31-33 while 

terminal 24 is communicating on communication buses 31-33. As Flood indicates: 

Access to the communication buses 31-33 is controlled by an arbitration 
circuit 40 which resolves conflicts when several devices request access to 
these busses at the same time. The arbitration circuit 40 determines which 
component of the communication section will have access to the shared buses 
31-33. A device seeking the buses sends a request signal to the arbitration 
circuit 40 via a line of the control bus 3 1 and the arbitration circuit grants the 
request to one device at a time by producing an access signal on another 
control line for that device. 

Column 7, lines 36-46. 

Thus, to whatever extent execution processors 18 directly access RAM 38 over 
communication buses 31-33, execution processors 18 do not communicate over 
communication buses 31-33 concurrently with terminal 24 and only one device may be 
transmitting data to or receiving data from RAM 38 at a time. As a result, no 
"communication link" that forms a "complete path" between terminal 24 and execution 
processors 1 8 is ever established, despite any indirect communication of information from 
terminal 24 to execution processors 18. Thus, Flood does not disclose a management card 
operable to "establish a communication link . . . [that] forms a complete path that couples at 
least the client to at least the particular interface card" as recited by amended Claim 1 . 
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As a result, Flood fails to recite, expressly or inherently, every element of amended 
Claim 1. Amended Claim 1 is thus allowable for at least these reasons. Appellant 
respectfully requests reconsideration and allowance of Claim 1 and its dependents. 

Although of differing scope from Claim 1, Claims 7, 14, and 21 include elements that, 
for reasons substantially similar to those discussed with respect to Claim 1, are not disclosed 
by Flood. Claims 7, 14, and 21 are thus allowable for at least these reasons. Appellant 
respectfully requests reconsideration and allowance of Claims 7, 14, and 21, and their 
respective dependents, including without limitation Claims 4-6, 10-13, 16, and 18-20. 

D. The rejection of Group 3 (Claims 22 and 24-26) under 35 U.S.C. § 102(e) 
is improper 

Claims 22 and 24-26 also stand rejected under 35 U.S.C. § 102(e) as being anticipated 
by Flood. Appellant respectfully submits that these claims are clearly patentable over Flood. 
Appellant respectfully submits that these rejections are therefore improper and should be 
reversed by the Board. 

Claim 22 recites: 

A system for communicating management information, comprising: 
a first interface card coupled to a first network device that uses a first 
operating system; 

a second interface card coupled to a second network device that uses a 
second operating system; and 

a management card coupled to the first interface card and the second 
interface card, the management card operable to: 

receive a command from a client, the command identifying an 
interface card or a network device associated with an interface card; 

establish a communication link between the client and a 
particular one of the first interface card and the second interface card 
selected in response to the command communicated by the client; 

configure management information for the operating system of 
the network device associated with the particular interface card; and 

communicate the management information using the 
communication link. 

Flood fails to recite either, expressly or inherently, every element of Claim 22 for at least 
several reasons. As discussed in greater detail below with respect to Claim 3, Flood, at a 
minimum, fails to disclose "[a] first interface card [that] is coupled to a first network device 
that uses a first operating system" and "[a] second interface card [that] is coupled to a second 
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network device that uses a second operating system." As the Board previously noted, in 
addressing previously- appealed Claim 3, "the examiner's 'finding' of different operating 
systems in Flood is nothing more than speculation and has no support in the reference." First 
Appeal Decision, Page 12. Moreover, as the Board previously agreed, "the Flood-Schneider 
combination [and, by extension, Flood alone] does not even discuss operating systems or 
different operating systems associated with different network devices." Id, Thus, Flood fails 
to recite "[a] first interface card [that] is coupled to a first network device that uses a first 
operating system" and "[a] second interface card [that] is coupled to a second network device 
that uses a second operating system." 

As a result, Flood fails to recite, expressly or inherently, every element of Claim 22. 
Claim 22 is thus allowable for at least these reasons. Appellant respectfully requests 
allowance of Claim 22 and its dependents. 

V. Issue III - Claims 2-3, 8-9, 15. 17, and 23 are patentable over Flood 

Claims 2-3, 8-9, 15, 17, and 23 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Flood in view of Schneider. Appellant respectfully submits that the 
proposed Flood-Schneider combination fails to support the obviousness rejections of these 
claims. Appellant respectfully submits that these rejections are therefore improper and 
should be reversed by the Board. 

A. Standard for Demonstrating a Prima Facie Case of Obviousness 

The question raised under 35 U.S.C. § 103 is whether the prior art taken as a whole 
would suggest the claimed invention taken as a whole to one of ordinary skill in the art at the 
time of the invention. See 35 U.S.C. § 103(a). The M.P.E.P. sets forth the strict legal 
standard for establishing a prima facie case of obviousness based on modification or 
combination of prior art references. "To establish a prima facie case of obviousness, three 
basic criteria must be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference (or references where 
combined) must teach or suggest all the claim limitations." M.P.E.P. § 2142, 2143. 
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Moreover, "[t]o establish prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. All words in a claim must be 
considered in judging the patentability of that claim against the prior art." M.P.E.P. § 2143.03 
(citations omitted). 

B. The rejection of Group 4 (Claims 2, 8, and 15) under 35 U.S.C. 
§ 103(a) is improper 

Claims 2, 8, and 15 depend from Claims 1, 7, and 14 respectively which have all been 
shown above to be allowable over Flood. Combining Flood with Schneider fails to remedy 
the omissions of Flood. For example, Schneider also fails to disclose "a management 
card. . .operable to. . .establish a communication link between [a] client and a particular one of 
[a] first interface card and [a] second interface card.. wherein the communication link forms 
a complete path that couples at least the client to at least the particular interface card" 
(emphasis added) as required by Claim 2 (based on its dependency on Claim 1). Schneider 
additionally fails to satisfy similar limitations of Claims 8 and 15. 

As a result, Flood and Schenider, both alone and in combination, fail to disclose, 
teach, or suggest every element of Claims 2, 8, and 15. Claims 2, 8, and 15 are thus 
allowable for at least these reasons. Appellant respectfully requests reconsideration and 
allowance of Claims 2, 8, and 15. 

C. The rejection of Group 5 (Claims 3, 9, 17, and 23) under 35 U.S.C. 
§ 103(a) is improper 

For example, Claim 3 depends from Claim 2, another dependent of Claim 1. Claim 2 

recites: 

The system of Claim 1, wherein the management card comprises: 

a switch operable to establish the communication link between the client 

and one of a first port and a second port of the management card; 

a memory operable to store mapping information associating the first 

port with the first interface card and the second port with the second interface 

card; and 

a processor coupled to the memory and the switch, the processor 
operable to: 

receive the command; 
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determine the port associated with the particular interface card 
using the mapping information; and 

command the switch to establish the communication link 
between the client and the determined port. 

Meanwhile Claim 3 recites: 

The system of Claim 2, wherein: 

the first interface card is coupled to a first network device that uses a 
first operating system; 

the second interface card is coupled to a second network device that uses 
a second operating system; and 

the processor is further operable to configure the management 
information for the operating system of the network device associated with the 
particular interface card. 

The proposed Flood-Schneider combination fails to disclose every element of Claim 

3. At a minimum, the proposed Flood-Schneider combination fails to disclose "[a] first 

interface card [that] is coupled to a first network device that uses a first operating system" 

and "[a] second interface card [that] is coupled to a second network device that uses a second 

operating system." As Appellant repeatedly noted during prosecution, the Examiner, in 

addressing this element, continues to assert an argument the Board has already rejected. See, 

e.g., Final Office Action, Page 7. In particular, the Examiner asserts that: 

Flood disclosed wherein: the first interface card is coupled to a first network 
device that uses a first operating system the second interface card is coupled to 
a second network device that uses a second operating system (col. 4, lines 33- 
49); and the processor is further operable to configure the management 
information for the operating system of the network device associated with the 
particular interface card (col. 4, lines 61-67). 

Final Office Action, Page 7. 

The Board, however, previously rejected this argument on appeal. 

In particular, the Board stated in its Decision on Appeal, issued May 24, 2005 (the 

"Board's Decision"): 

The [Flood-Schneider combination] makes no mention of first and second 
operating systems and of configuring management information for the 
operating system. The examiner's "finding" of different operating systems in 
Flood is nothing more than speculation and has no support in the 
reference.... The prior art applied in the examiner's rejection simply does not 
provide the support needed to reject claims 3, 9 and 17." 

First Appeal Decision, Pages 12-13. 
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Thus, as the Board notes, the proposed Flood-Schneider fails to disclose a "first 
operating system" and "a second operating system" and, thus, fails to disclose "[a] first 
interface card [that] is coupled to a first network device that uses a first operating system" 
and "[a] second interface card [that] is coupled to a second network device that uses a second 
operating system" as recited by Claim 3. Appellant has noted this deficiency repeatedly (see, 
e.g., June 8 Response, Pages 14-15), but the Examiner has failed to address this argument. 
In the Final Office Action, the Examiner again quotes the same language that the Examiner 
improperly relied on in rejecting Claim 3 prior to the first appeal of the present Application, 
contrary to the ruling of the Board. Final Office Action, Page 7. 

Thus, as both Appellant and the Board have noted, the proposed Flood-Schneider 
combination fails to disclose, teach, or suggest every element of Claim 3. As a result, the 
proposed Flood-Schneider combination can not properly be used to reject Claim 3. 
Moreover, this conclusion is in accordance with the findings of the Board. First Appeal 
Decision, Page 13. Claim 3 is thus allowable for at least this reason. Appellant respectfully 
requests reconsideration and allowance of Claim 3. 

Although of differing scope from Claim 3, Claims 9, 17, and 23 include certain 
elements that, for reasons substantially similar to those discussed with respect to Claim 3, are 
not disclosed by the proposed Flood- Schneider combination. Claim 9, 17, and 23 are thus 
allowable for the reasons discussed with respect to Claim 3. Appellant respectfully requests 
reconsideration and allowance of Claims 9, 17, and 23. 



I ■. 
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Conclusion 



Appellant has demonstrated that, for at least the foregoing reasons, the present 
invention, as claimed, is clearly patentable over the references cited by the Examiner. 
Therefore, Appellant respectfully requests the Board to reverse the final rejection of the 
Examiner and instruct the Examiner to issue a Notice of Allowance of all pending claims. 

The Commissioner is hereby authorized to charge the large entity fee of $500.00 
under 37 C.F.R. §§ 1.191(a) and 1.17(b) for filing this Appeal Brief to Deposit Account No. 
02-0384 of Baker Botts L.L.P. Although no other fees are believed to be due at this time, the 



Commissioner is hereby authorized to charge any additional fees and/or credit any 
overpayments to Deposit Account No. 02-0384 of Baker Botts L.L.P. 



Respectfully submitted, 



BAKER BOTTS L.L.P. 



Attorneys for Appellant 




Todd A. Cason 
Reg. No. 54,020 
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The Claims: 

1. (Previously presented) A system for communicating management 
information, comprising: 

a first interface card; 

a second interface card; and 

a management card coupled to the first interface card and the second interface card, 
the management card operable to: 

receive a command from a client, the command identifying an interface card 
or a network device associated with an interface card; 

establish a communication link between the client and a particular one of the 
first interface card and the second interface card selected in response to the command 
communicated by the client, wherein the communication link forms a complete path 
that couples at least the client to at least the particular interface card; and 

communicate management information using the communication link. 



2. 

comprises: 



(Previously presented) The system of Claim 1, wherein the management card 



a switch operable to establish the communication link between the client and one of a 
first port and a second port of the management card; 

a memory operable to store mapping information associating the first port with the 
first interface card and the second port with the second interface card; and 

a processor coupled to the memory and the switch, the processor operable to: 
receive the command; 

determine the port associated with the particular interface card using the 
mapping information; and 

command the switch to establish the communication link between the client 
and the determined port. 
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3. (Original) The system of Claim 2, wherein: 

the first interface card is coupled to a first network device that uses a first operating system; 
the second interface card is coupled to a second network device that uses a second operating 
system; and 

the processor is further operable to configure the management information for the operating 
system of the network device associated with the particular interface card. 

4. (Original) The system of Claim 1 , wherein the communication link comprises 
a serial communication path. 

5. (Original) The system of Claim 1, wherein the command comprises 
information selecting one of the first interface card and the second interface card. 

I 

i 
i 

6. (Original) The system of Claim 1, wherein the management information 
comprises information used to configure a network device associated with the particular 
interface card. 
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7. (Previously presented) A method for communicating management 
information performed by a management card, comprising: 

receiving a command from a client, the command identifying a particular one of a 
first interface card and a second interface card; 

establishing a communication link between the client and the particular interface card 
in response to receiving the command, wherein the communication link forms a complete 
path that couples at least the client to at least the particular interface card; and 

communicating management information using the communication link. 

8. (Original) The method of Claim 7, further comprising storing mapping 
information that associates a first port of a switch with the first interface card and a second 
port of the switch with the second interface card, the step of establishing a communication 
link comprising determining the port associated with the particular interface card using the 
mapping information and establishing the communication link between the client and the 
determined port using the switch. 

9. (Original) The method of Claim 7, wherein: 

the first interface card is coupled to a first network device that uses a first operating 

system; 

the second interface card is coupled to a second network device that uses a second 
operating system; and 

further comprising configuring the management information for the operating system 
of the network device associated with the particular interface card. 

10. (Original) The method of Claim 7, further comprising operating the client to 
generate the command and the management information. 

1 1 . (Original) The method of Claim 7, wherein the communication link comprises 
a serial communication path. 

12. (Original) The method of Claim 7, wherein the command comprises 
information selecting one of the first interface card and the second interface card. 



ATTORNEY DOCKET NO. 
063170.0320 



A.4 



PATENT APPLICATION 
USSN 09/436,920 



13. (Original) The method of Claim 7, wherein the management information 1 
comprises information used to configure a network device associated with the particular 
interface card. 
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14. (Previously presented) A management card, comprising: 

a switch coupled to a first interface card and a second interface card; and 

a processor coupled to the switch and operable to: 

receive a command communicated by a client, the command identifying a 
particular one of the first interface card and the second interface card; and 

command the switch to establish a communication link between the client and 
the particular interface card, wherein the communication link forms a complete path 
that couples at least the client to at least the particular interface card. 

15. (Original) The management card of Claim 14, wherein: 

the switch comprises a first port coupled to the first interface card and a second port 
coupled to the second interface card, the switch operable to establish the communication link 
between a client and one of the first port and the second port; 

the management card further comprises a memory coupled to the processor and 
operable to store mapping information that associates the first port with the first interface 
card and the second port with the second interface card; and 

the processor is further operable to: 

determine the port associated with the particular interface card using the 
mapping information; and 

command the switch to establish the communication link between the client 
and the determined port. 

16. (Original) The management card of Claim 14, wherein the processor is further 
operable to communicate management information using the communication link. 

17. (Original) The management card of Claim 14, wherein: 

the first interface card is coupled to a first network device that uses a first operating system; 
the second interface card is coupled to a second network device that uses a second operating 
system; and 

the processor is further operable to configure the management information for the 
operating system of the network device associated with the particular interface card. 
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18. (Original) The management card of Claim 14, wherein the communication 
link comprises a serial communication path. 

19. (Original) The management card of Claim 14, wherein the command 
comprises information selecting one of the first interface card and the second interface card. 

20. (Original) The management card of Claim 14, wherein the management 
information comprises information used to configure a network device associated with the 
particular interface card. 
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21. (Previously presented) A system for communicating management 
information, comprising: 

means for receiving a command from a client, the command identifying a particular 
one of a first interface card and a second interface card; 

means for establishing a communication link between the client and the particular 
interface card in response to receiving the command, wherein the communication link forms 
a complete path that couples at least the client to at least the particular interface card; and 

means for communicating management information using the communication link. 
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22. (Previously presented) A system for communicating management 
information, comprising: 

a first interface card coupled to a first network device that uses a first operating 

system; 

a second interface card coupled to a second network device that uses a second 
operating system; and 

a management card coupled to the first interface card and the second interface card, 
the management card operable to: 

receive a command from a client, the command identifying an interface card 
or a network device associated with an interface card; 

establish a communication link between the client and a particular one of the 
first interface card and the second interface card selected in response to the command 
communicated by the client; 

configure management information for the operating system of the network 
device associated with the particular interface card; and 

communicate the management information using the communication link. 

23. (Previously presented) The system of Claim 22, wherein the management 
card comprises: 

a switch operable to establish the communication link between the client and one of a 
first port and a second port of the management card; 

a memory operable to store mapping information associating the first port with the 
first interface card and the second port with the second interface card; and 
a processor coupled to the memory and the switch, the processor operable to: 

receive the command; 

determine the port associated with the particular interface card using the 
mapping information; and 

command the switch to establish the communication link between the client 
and the determined port. 



24. (Previously presented) The system of Claim 22, wherein the communication 
link comprises a serial communication path. 
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25. (Previously presented) The system of Claim 22, wherein the command 
comprises information selecting one of the first interface card and the second interface card. 

26. (Previously presented) The system of Claim 22, wherein the management 
information comprises information used to configure a network device associated with the 
particular interface card. 
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[57] ABSTRACT 

A programmable controller for operating a machine to 
carry out programmed functions includes a plurality of 
program processors. Each of the program processors is 
operable to execute simultaneously a different user con- 
trol program that directs the operation of the machine 
to perform specific functions. Each of the program 
processors includes a memory for storing the user con- 
trol programs and function chart data. The function 
chart data comprises a series of descriptor files each of 
which contain an identification of a user control pro- 
gram to execute, a transition condition that indicates 
when the execution of that user control program is to 
ter min a te, and which descriptor file is to be processed 
next as well as the program processors to process it. A 
mechanism is also provided to enable the program pro- 
cessors to execute other programs in as background 
tasks without adversely affecting the execution of the 
control programs. 
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Dnnniiiu.iit.fj _„^^ Mates. Each control step is defined by a separately exe- 

• ^^^^sTS^^o^ 1 ™ cutable ladder program which is easy to understand and 

MULTIPLE TASK PROCESSORS which may be executed at a very high scan rate. The 

tk- cm „r.i.. j_. . . sequence in which the separate control steps are exe- 

iJ^J^tl^ £™?T M TT P ? , S am ^ ab ^ C ° ntr ° 1 - 3 ="tcd is defined by the function chart program which is 

SSS^,™ NOS - 3 ' 810,1 185 * 8enCTal ^P««ion of how the controlledmachine or 

' ^ 158 ' 4,163,534; and ^.442.504. process „ to operate . The user may thus define the 

BACKGROUND OF THE INVENTION general manner in which the machine or process is to 

o-___„ . , . „ . .. operate using function chart constructs, and then define 

i J^S?" c ° ntro " crs are tyP«=aUy connected to 10 the detailed operation of the machine or process in 

E^f^T 1 ^ ** ^ ^ niachme separate, easilyWmged ladder programs 

d^Lw ; n«"^ y °P erate T the ^P™«« « accor- The previous applications of fLctionchart and lad- 

ZZ^JFSS: fa f ro ? amn »?We control- der programs have been in programmable controls 

f 0 ?e^X^t^T a m "^!!/? ted P * tent8 ' » »nSlc processor for eS« the program? 

a^n^u^t^^^T " ^ m * mCm °^ 15 Recent, y a programmable controller has Se^cSL. 

•odmcluto mstructjons which are read out in rapid ceived which employs several processors each capable 

stS^nfd^. » examinejte condition of of stotmtane^executing a separate ladd^pr^gC 

^r^J^t nf^f! *f.^ > . n . tr0llcd 5 < ' u *P mrat ' This type of controller requires a mechanism for crordi- 

™ ^^^Z, ae ^ etgUC * ck *? ted 0peratin 8 devices nating the ladder programs being executed by Sedif- 

on the controlled equipment contingent upon the status 20 ferent processors. y 00 

^Z^ t ^^^ iDed !^ Dt ^2 C ^ , Another Problem developed when previous pro- 

rarSlv £^^™™hv ™^ to ^nmimable controller, had to execute complex routines 

SnfwwTS? £2£T^f? COOtr °i ler ty F« 1 mstnlc - such as solving an equation. Such computational tasks 

tons which m raednnn to large sued controllers in- often tied up the processor for relatively long periods of 
eludes not only instructions that manipulated single-bit 23 time delaying the execution of other ram of bladder 

EetanX£££££ ^^^^ iastra ^ program. TOs could result fa fZ5£%££ of tie 

« w^T^ ft" and P 0 "?* ■ """trolled equipment not being supervised frequently 

era and other more complex instructions. Such instruc- enough by the programmable controller * 

tons have become quite standardized in the industry «""™iier. 

and they may be directly associated with elements of a 30 SUMMARY OF THE INVENTION 

1 ^J^^tZ^\ WBde T°° d J iy , COa ^ 1 A P«>8««°»»»le controller executes, a single ma- 

US pT'n^!^ nTT^T* 1 f^o ^ ^ m Chine "P"*-™ P™«™» «">bling a machine to carry 

^40»n£!te ^l 3 ,' 8 ^ 6 ! 9 «? » UA Pat - out a Pi*"** of programmed functions. Each step of 

V°;.7' . ' 702 ""ve been developed to assist the user in the machine operation program is defined as a seoarate 

InTtSnT P SUCh pr0grammaWe controller deludes a pluramTof fadivia^T^r mSlul« 

tv» ;„„..„ . , cacn of which is capable of simultaneously executing a 

To insure that the programmable controller can re- user defined control program. A storage means is oro- 

n P ^£ q ^ y ,£ ChangC m thcStatUS sensing devices vided to store the coAol^wS dTwIndfcatint 
^eS^^S rt 18 «*«*'•*■* the con- 40 the sequence in which the cc£3progran£« tote 

wS^Tt^^!^? 1 S ro8ram re P eate 5 Uv atav «y «ecuted. The programmable controller^ incwdet 

ugh rate. The rate at which a programmable controller one or more input/output (I/O) modules for interfacing 

aTtnf^ o^r^T? * ^ ^^^^ -well it to sensors and^uTton T^n tiiel^oSri FESX 

Actors wnlcE d2lS2^!2?Sr , i.?? J? Primary TbeSC 1/0 modules ^ interface the controller to the 
m^T^w^r^^ eth ^2 te M wtach ^ Prosram- 45 sensors and actuators directiy or indirectly through 

mable controller can repeatedly execute, or "scan", the remote I/O adapters. mrougn 

°°Wliil^ P l^WH;»^^ .,„. Typically, the operation of the controller is defined 

laAMW S ^X^SS^JSSST "^r* 0 "" by a ^ chart and a series of control 

Sw. ^L™".^.^ ^ rt f ° r relatively small to me- programs, such as ladder programs. The function chart 
J^f^. 0lta f*' «» e y become cumbersome and 50 sets out the overall process to b7 r^rforaed to T£- 

mefficient to «e m large control tasks. Large ladder quence of steps. The function chart SkTn down inw 

SrK ^hT'T? "5 to , UndCTStand > »«ri« of descriptors each of wSln^ns da^i 

d^lt to trouble shoot, and require a long time to tying a processing step to be performed, . S, 

ti c * |* j» „ condition that occurs when the step is completed and a 

m£ itwS Sti^L™ 0 * ^ 7,221 ', 1 fikd °? 55 to the next descriptor in the series. ThedeS 

^f'^ 19 i 5 «»^tled Programmable Controller with tors of the function chart guide the overall flow of 

^^J^h ft*"?* tW» Problem. program execution. The pr^Z^k^xo^ tof 

1^.^^ descjfted therem includes a processor elude, means for interpreting Selescripto^ to control 

™ ^T.* P , ° fS ?^ todd ? contro1 P»>- the execution of the^ntrol programTby Se pSlry 

grams that are lomcaUy related to each other by a 60 of processors. p y 

stored function chart program, and the processor is Each processing step is assigned to one of the nroc«- 

S , H ^t tlK ^ ftmCtion chart Pt^nun sor module, for execution™^ fa rurti* defined 

a^S b^^v° ,,eS laddCT P ro « rams bv a Process control program wh^faettSer? convS 

H«T?f y S ed by P«««»or at any tional ladder diagram program or a high level ' 

Sk, ^„^,.iil^f ^ du ff vered thit lar 8« «"»trol « program, to the preferred^bodinfent * toHSSSi 

^ ^T!i y ^^ifl dOWn mto J e F B ?! e cont ? 1 P 10 ^ * compiled and stored in a local memory of 

stepswtoch are executed m a sequential order as the the respective processor module that has been assiimed 

controlled machine or process advances through its to execute ^program. Once a P^^TmcZe^ 
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gins executing a specific control program, it repeatedly 
carries oat the execution until the associated transition 
condition occurs. At that time the next descriptor 
pointer is read for information as to the next step to 
perform. 5 

The programmable controller further includes a 
mechanism for allotting a portion of the program execu- 
tion time of each processor module for the execution of 
programs other than control programs. This allows 
complex time consuming tasks to be executed in a time 10 
slice manner without adversely interfering with the 
execution of the control programs. 

In an embodiment of the present invention, each of 
the processor modules has an external interrupt which 
enables an external device to be coupled directly to the 15 
processor module. This external device is able to inter- 
rupt the regular program execution by the processor 
module and cause an interrupt routine to be executed. 

A general object of the present invention is to pro- 
vide a programmable controller which employs several 20 
processors to control the operation of a machine. 

An object of the present invention is to provide a 
programmable controller wherein portions of a single 
m ac hin e operation program are executed simulta- 
neously on several parallel processors. 25 

Another object is to incorporate a mechanism in the 
programmable controller which directs the processor's 
execution of a plurality of control programs. 

A further object of the present invention is to periodi- 
cally execute other time ocosnming programs by the 30 
processor means without such execution having a sub- 
stantial adverse affect on the execution of control pro- 
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In the drawings which illustrate the embodiments of 
the present invention: 

FIG. 1 is a perspective view of a programmable con- 
troller which employs the present invention; 

FIG. 2 is a schematic block diagram of the program- 40 
mable controller system shown in FIG. 1; 

FIG. 3 is a schematic block diagram of the System 
Controller for the programmable controller of FIG. 2; 

FIG. 4 is a schematic block diagram of a Program 
Execution Processor of the programmable controller 43 
shown in FIG. 2; 

FIG. 5 is a schematic block diagram of the random 
access memory of the Program Execution Processor of 
FIG. 4; 

FIG. 6 is a schematic block diagram of the remote 50 
input/output scanner of the FIG. 2 programmable con- 
troller; 

FIG. 7 is a diagram of the System Controller memory 
data structure; 

FIG. S is a diagram of the I/O Scanner memory data 55 
structure; 

FIG. 9 is a diagram of the Program Execution Pro- 
cessor memory data structure; 

FIG. 10 is an exemplary function chart diagram; 

FIGS. 11 A, B and C are illustrations of the descrip- 60 
tor file data structures generated from the function 
chart program of FIG. lfr, 

FIGS. 12 A and B show the entries in the mailboxes 
of FIG. 14 for different types of messages; 

FIG. 13 is a flow chart of the programmable control- 65 
ler initialization routine; 

FIG. 14 is a schematic representation of a portion of 
the system of FIG. 1 used to described the communica- 



tion of messages between modules of the programmable 
controller; 

FIG. 15 depicts a flow chart of the program steps to 
initiate the sending of a message from one module to 
another in the programmable controller; and 

FIGS. 16, 17, 19 and 19 are flow charts of portions of 
the software for interpreting function chart data and 
executing user control programs. 

DETAILED DESCRIPTION OF THE 
INVENTION 

With initial reference to FIG. 1, a programmable 
controller 10 of the present invention is housed in a rack 
12 which includes a series of slots that receive a plural- 
ity of printed circuit board modules. These functional 
modules connect to a mother board which extends 
along the back surface of the rack 12 to provide a back- 
plane 11. The backplane 11 has a plurality of module 
connectors which are interconnected by a conductive 
pattern on the backplane. The backplane 11 provides a 
series of signal buses to which the modules connect. 
The rack 12 contains a power supply module 14* a sys- 
tem controller 16, a number of program execution pro- 
cessor modules 18 and a plurality of remote input/out- 
put (I/O) scanner modules 20, although only one scan- 
ner module is required. The remaining locations in rack 
12 are empty and the slots are covered by blank plates 
until additional functional modules are to be inserted in 
these slots. The physical construction of the rack 12 is 
disclosed in U.S. patent application Ser. No. 06/909,710 
filed on Sept. 22, 1986, and assigned to the same as- 
signee as the present invention. 

Up to four remote I/O scanner modules 20 interface 
the controller 10 to external remote I/O racks 17 via 
serial I/O data links, such as link 15. Each remote I/O 
rack 17 has a plurality of local I/O modules 19 which 
are coupled to individual sensors and actuators on the 
controlled equipment. The local I/O modules 19 may 
take many forms and may include, for example, D.C. 
inputs or outputs, AC. inputs or outputs, analog inputs 
or outputs, and open or closed loop positioning mod- 
ules. The I/O racks 17 and networks 15 employ conven- 
tional interface and communication technology. The 
remote I/O rack 17 also contains an adapter module 19"; 
such as the one described in U.S. Pat. No. 4,413,319, 
which controls the transmission of data via the I/O 
network 15 between the I/O modules 19 and the scan- 
ner modules 20. 

The system controller 16 is connected through cable 
25 to a programming terminal 24, which is used to load 
the user programs into the programmable controller 
and configure its operation, as well as monitor its per- 
formance. The terminal 24 is a personal computer pro- 
grammed to enable the user to develop the control 
programs on the terminal, which programs are then 
downloaded into the programmable controller. Once 
the programs have been loaded into the programmable 
controller 10 and its operation debugged, the terminal 
24 may be disconnected from the system controller 16 if 
further monitoring is not required. The system control- 
ler 16 may be also connected via a cable 26 to a local 
area network 28 over winch it may receive data and 
programming instructions, as well as issue status infor- 
mation and report data to a host computer. This enables 
a central host computer or central terminal to program 
and control the operation of a plurality of programma- 
ble controllers on a factory floor. 



4,937,777 

5 6 

•^["f"' l^P 3 of a fifction chart program are as- tern housekeeping functions, such as providing an indi- 

*2*%hZZ?£Z? Pr °f am " CCUti0n mod - of the system status and supervising access to the 

cues is. The user control program for each step is stored backplane 11 

ZJo^^LSS^n c ^ COIT f Sp f 1 ndin 8 Program During normal operation of the programmable con- 

e»cution module 18. For example the user control 3 trailer, the system controller takes care of communica- 

TZF^l * convenaonal ^ dcr Program. Sev- tion with the external devices that are connected to it, 

^,^r^^iL? 8ramS Tl CXCCUted simu,t "- 3uch >» network 28 aid programming terminal 24. The 

< ?,™ ere "5 on<s £ P«>g«w> execution most significant task is communicating with the termi- 

A| other times a "background task" may be nal 24 to provide information allowing the operator to 

,?r ne , P rogra ™ exccutlon mod , lJc » white 10 monitor the system performance and to detect faulty 

ai^« module 18 executes a user control program. sensors or actuators. Another task supervised by the 

JS^a C ° UISe Car y ymg omalB « control system controller is the exchange of date with a host 

S^Z.^T^£'SLT !UtKm . M mptt * computer or a peer programmable controller via the 

SeT/O ^X^f,^ one W of local net work 28. This enables the host computer 

CaHcd . for "y °f P«>- 15 to ''o'tect statistics from one or a number of program- 

S^ 1 ^^! ^l P f 0 S! ,n eXeCUtXm mod ^ Ie 8150 nMlWe controllers regarding their operation. In addition 

^cSK^Sf M S!.°!S^f Ublcintbc f° Wtk ™ another function Ae system control- 

^°'ftf mmg module 20 that services the respective ler 16 receives all programming changes and sees to it 

SXt£Z££X* 1/0 ^ U 0btamed ™ program in thfc^eZnding 8 prog^rT^u 

therack backplane 11. 20 fen module 18 is updated. For example, this includes 

K^^"w P ^fT C ^ utXM rnodule completes , func- adding, deleting and changing variolas rungs of the 
toon chart step, it sends a command to the program ladder program. 

"f^ 00 f2°f ule 18 co ° t * inin | the next step to be The system controller as shown schematically in 

oommand identifies the next step and FIG. 3 connects to the backplane buses 21-23 and is 
msteucs that program execution module 18 to begin 25 divided into three sections (delineated by dashed lines) 
8 for backplane interface, processing and communication 

Hardware operations. The backplane interface section supervises 

T . , . the backplane access for all the rack modules and inter- 

. J? XT °f^f date and commands to be transfered faces the controller module 16 to the backplane 11. The 
among the modules of the programmab e controller, the 30 processor section executes a supervisory program for 

Jfh!f^ l ° eC ^ a3 , ShOWn - ™ mG .^ *" controUer 10 The communication if^nar- 

ot^i^^r^™ L?" UUnS * i rfe 5«noe to ily responsible for communicating with external termi- 
fiT^ 8 ^ ? drawmgs that contain the details of nal 24 and local area networks, such as LAN 28. Each 
ttiecomponent represented by the block. Each of the of the processor and communication sections include a 
modules ts connected to the rack backplane 11 which 33 set of internal buses, communication bus^SlSo and 
consats of separate control data and address buses, processor buses «l-« respectively 

»T,^i eaPeCttV 1 ,™ C COnt T t> ' 1 buS 21 con8i « t » of » Various circuits connected to the communication 

wh ^ 1 ».module may con- buses control the interfacing of the system controUer 16 
SfT^^ZS*. control signals required for to the programming terminal 24 and the local area net- 

SkwE JJ%££,V* £ %L ^ ? Wt » 40 work 28. T^cZmunication buses consSTofTntrol 

^? X? ^r^rJ^llf ^ tSW1 ^ e - . bus 31 having a number of individual control lines run- 

^ZJ^ Vff«md embodiment, each of die system ning between various components in the communica- 
IS^I tirES"" " C ^ tl ? n modules 18 tion section, an eight bit wide data bus 32 and a sixteen 
mL T^J^J^Z modules f c!udes a / emov - Wt widc address bus 33. The communication section is 
able daughter board containing a local memory for data 45 built around a microprocessor 30, such as the model 
rl^ 8 8 mStrn ? tK>ns for «"* module, The daugh- Z80 manufactured b/Zilog, Incorporated Tte ^ 
te ^oard contains abattery to sustain the memory when processor 30 executes marfune l2«uage instruction^ 
power ^removed from the controller. The memory 134 which are stored in a read-only memoly (ROM)34 Tte 
Z^ tlT^, %5 T™?. ^° dUl , e »" 1/0 instructions are fetched from the ROM, decoded and 

T£Z^!Z^ ^ ^ °f 68011 of thc sensor 50 then executed by the microprocessor 30 to carry out the 

tZSU?* of each of the controlled communication functions. TThTWgra^^tohW 

act^orsconnected to the scanner module 20. The these functions is similar to that e^pSySl m prev^us 
system controller's memory 69 contains various seg- programmable controllers. 

merits that store data regarding the system status and A conventional address decoding circuit 36 receives 

,^er o a r^^ e F^?T ti0n ^l^T^S " CaCh ^ "y nucroprocessor 30^oT 

system operations. Each of the processor modules 18 codes it to produce the proper set of signals on control 

^IL^T,"?* 8 * mCm ° ry , 106 whkh tores the line. 31. Fof example, if the rmcroproceSofa aSess- 

^S!^ ^ P™ 8 ™™ ** fa 8 «•» ROM ■ *• "ddress dec^St 36^1 

F^-hff^^l.^;.-™ , , ^ recognize that the address sent by the microprocessor 

Each of the functional modutes of the programmable 60 30 on bus 33 is within the range of addresses^ which 
coroner 10 win be described in detail in the following the ROM is located. Once if has ^^Sed which 

device in the communications section is to be accessed, 
System Controller ^ addresa decode circuit 36 produces control signals 

a- • * - „ for the device to carry out the access. 

As noted previously, the system controller module 16 65 Two serial input/output devices, UART 46 and serial 
^^^^T m ? m ^ 0n T****? Program- inpul/output controller (SIO) 48, are also connected™ 

^ lc ^ D ^? Ucr to cxtcnud tenninals and local area the three communication buses 31-33. TheU^T « 
networks. The system controUer 16 also performs sys- may be any of several commercially available universal 
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aa^chr^^n^v^tranamitto integrated circuits. cesser buses 62 and (53 of the system controller module 
I^Y^i coovem the parallel data which is pres. 16. Specifically, the first set of gates 56 provides an 
™f ^^l™^ 0 * <^ b«s 32 into a properly eight bit bidirectional connection of the communication 
tormatted serial signal which is fed to an input/output section data bus 32 to the data bus 62 of the processor 
line dnyer/reca vex 50. The hue driver 50 provides 5 section; and the second set of gates 5* connects the two 
output signals corresponding to any one of several serial address buses 33 and 63. The data gate 56 consists of 
signal standards, such as RS232, RS423 or RS422. The two sets of eight individual tristate data gates, each set 
serial I/O communication controller 48 may be any of controlling data flow in one direction between the two 
several commercially available integrated circuits buses 32 and 62. Only the lower eight lines of the pro- 
vrtucn f**^ synchronous serial communication 10 cesser data bus 62 are coupled to the eight bit communi- 
cnannels. Tbc SIO 48 interfaces the communication cation section data bus 32. As addressing will only 
section of t^ system controller 16 to local area net- occur from the processor section to the communication 
woriocaanected to the kne drivers 52 and 54, such as section, address gates 58 consist of one set of sixteen 
SS^S^ ^programming terminal 24, tri-state signal gates coupling the sixteen communica- 

sftownm FIG. 1, is connected to one of these line driver 15 tion address bus lines 33 to the lower sixteen address 
55^" _ . , . . . . K«ws in the processor section. An interbus control cir- 

Ateo located withm the communication section is a cuit 60 is connected to control lines 61 and 31 from the 
random i access memory (RAM) 38 for temporary stor- processor and the communication sections, respec- 
age of data received from or to be sent to the various tively, and in response to access request signals from 
«ternal devices connected to the system controller. 20 arbitration circuits 40 and 64, the control circuit 60 
I He RAM 38 may be accessed via address bus 33 so that enables the data and address buffers 56 and 58 
J^J? written mto or read from the memory via The processor section is built around a sixteen-bit 
bus 32 deeding upon enabling signals from control niicroprocessor 66, such as a model 68010 manufactured 
bus 31. RAM 38 mcorporates a parity circuit winch by Motorola Inc., which executes program code stored 
analyzes each digital byte being stored in the RAM and 25 in read only memory 68. The 68010 microprocessor is 
Ppd»ces a parity bit using conventional techniques. essentially a memory mapped device and does not have 
Tms parity bit is employed to check the integrity of the any input/output lines directly connected to it. There- 
data read from the random access memory 38. A direct fore, its access to other components on the processor 
memory access (DMA) circuit 42 is provided to enable bus must be accomplished through issuing addresses on 
rapid data exchange between the SIO 48 and the RAM 30 bus 63. The address sent from the microprocessor 66 is 
38 during the communication process. The DMA cir- decoded in an address decode circuit 70 to produce the 
curt42 aflowsthe SIO 48 to access RAM 38 to store or proper control signals for the accessed component. The 
obtain data which have been received or will be trans- processor address decoder 70 functions in much the 
nutted over their respective external communication same manner as the communication section address 
ch a nnel s, 35 decoder circuit 36. The processor section also contains 

Access to the communication buses 31-33 is con- an interrupt processor 72 which controls interrupts to 
trolled by an arbitration circuit 40 which resolves con- the microprocessor 66 and provides the proper instruc- 
flicts when several devices request access to these buses tion address vectors. 

at the same time. The arbitration circuit 40 determines A data transfer acknowledge and bus error 
which component of the communication section will 40 (DTACK/BERR) circuit 74 is also connected to the 
have access to the shared buses 31-33. A device seeking processor control bus 61. Circuit 74 responds to signals 
the buses sends a request signal to the arbitration circuit from the various components in the processor section to 
40 via a Ime of the control bus 31 and the arbitration acknowledge the completion of a data transfer and issue 
circuit grants the request to one device at a time by bus error signals in the event of improper adoxessing or 
I h "cm? an access signal on another control line for 45 failure of data transfer. These signals are acted on by the 
that device. microprocessor 66 which takes corrective action. The 

A c ounter/timer circuit (CTC) 44 connects to the processor section also includes clock circuit 89 that 
co mm u n ica t ion buses 31-33 and to an interrupt terminal contains the main system clock and a real time clock. A 
on niicroprocessor 30 in order to process interrupt re- system status circuit 88 receives input signals related to 
quests from the other components within the communi- 50 the status of the entire system 10 and provides an indica- 
cations section. The CTC 44 is also configured as a tion of that status. 

timer to produce an interrupt request to the micro- The main random access memory (RAM) 69 for the 
?£ oc ^^ OT 30 * a Periodic interval, such as every system controller 16 is also connected to the processor 
10 millisecond*, so that various routines may be periodi- buses 61-63. The RAM 69 is a static memory containing 
catty executed regardless of the task then being per- 55 393,216 (3S4K) memory locations each of which is 16 
formed by m^processor 30. In response to an inter- bits wide and serves as the system memory for the entire 
nipt request from the CTC 44, the microprocessor 30 controller 10, The system memory 69 can be directly 
reads a vector from the CTC 44 directing the micro- accessed via the backplane 11 by other modules in the 
processor to-the appropriate interrupt service routine system without the intervention of the central process- 
stored in ROM 34, such as performing a data I/O re- 60 ing unit 66 within the system controller 
quest from either U ART 46 or SIO 48. FIG. 7 illustrates the data structures within the main 

Referring still to FIG. 3, the processor section is system memory 69 included in the system controller 
linked together by a set of buses that comprise control module 16. The system memory 69 stores separate data 
fanes 61, * sixteen bit data bus 62 and a twenty-three bit files, which contain data for forming specific func- 
address bus 63. Access to these buses is controlled by an 65 tions during the operation of the programmable control- 
arbitration circuit 64 similar to circuit 40 on the commu- ler. The data structures include various forms of data 
mcanon buses. Two sets of data gates 56 and 58 extend such as integers, floating point numbers, ASCII charac- 
between the communciation buses 32 and 33 and pro- ters and various control structures. The first file 200 is a 
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directory of the other files stored in the system control- Communication parameters are also stored in this 
ler memory 69. The remaining memory is divided into a section 20$ for configuring the UART 46 and the serial 
system status file 201, system data table 202 and a set of I/O module 48 within the communication section of the 
system support files 203. system controller 16. Among other things these parame- 

The system status file 201 contains data relating to the 5 ters include baud rate, word size and control bits for the 
configuration of the entire programmable controller 10. serial data signal format For example, parameters for 
Included in this file is information identifying the van- communicating with the operator terminal 24 are stored 
ous user selectable features of the programmable con- in this portion of the system memory. In addition, as 
troller that have been enabled by the system operator. noted previously, a number of programmable control- 
The real time clock data regarding the time of day, 10 lers may be connected via the local area network 28, in 
month, day and year are also included in this portion of which case, parameters must be provided in each con- 
the system memory. Digital words indicating the occur- troller instructing them how to communicate over the 
rence and type of various system faults and errors, as network. 

well as pointers indicating the program instruction Referring again to FIG. 3, the processor section of 
being executed when the fault occurs are stored within 15 the system controller 16 interfaces with the backplane 
another sub-file of this section. A section of the system buses of rack 12 via a plurality of components that are 
status file 201 also lists the number and type of all the coupled to both sets of buses. Specifically, the back- 
active modules on the system as well as the relative plane data bus 22 is connected to the processor data bus 
module number and address pointers necessary to ac- 62 by a set of bidirectional data transmission gates 78 
cess each module. For example, if more than one pro- 20 and the backplane address bus 23 is connected to the 
gram processor module 18 or remote I/O scanner mod- processor address bus 63 by another set of bidirectional 
ule 20 is present in rack 12, the user must assign a unique gates 76. When the system controller 16 seeks to exer- 
number via a thumb wheel on the module to distinguish cise control over the backplane 11 of the programmable 
the various modules of that type. The thumb wheel controller 10, a master mode control circuit 81 responds 
setting is read by the system controller during initial 25 to signals on the control lines of the processor bus 61 
start-up of the system and stored in this portion of the and issues the proper control signals over the backplane 
system status file 201. control bus 21 to access other modules within the rack 

The system data table 202 contains data that is shared 12. 
by more than one module. For example, results of van- When another module within the rack 12 seeks access 
ous computations from one program processor module 30 to the system controller 16, in order to read the contents 
18 may be stored in this portion of the system memory of main RAM 69, for example, the system controller 
so that other program processor modules may readily becomes subordinate to the control of the backplane 11 
access the data. Memory space is allocated within the by this other module. In this circumstance, a slave mode 
system data table 202 to store the data that was received control circuit 82 within the system controller 16 re- 
or that will be transmitted via the various external com- 35 sponds to the address of the system controller that ap- 
municarion links of the system controller's communica- pears on the backplane address bus 23 and to control 
tkra section. Other modules in the system 10 are directly signals on the control lines of the backplane bus 21 
able to access these storage locations. which lead from the other module. In response the slave 

The system data table 202 also contains the value of mode control 82 issues signals to transmission gates 76 
various system counters and variables which are either 40 and 78 enabling the other backplane module to access 
used by the system controller 16 or which are com- the system controller 16. In this latter instance, the 
monly used by a number of other modules such as pro- master mode control circuit 81 is in a dormant state, 
gram processor modules 18 or the I/O scanner modules The two bus gates 76 and 78 receive enabling control 
20. The final sub-file within the system data table 201 is signals from the master or slave mode control circuits 
a space allocated for the user defined data for various 45 81 and 82 via the lines of control bus 61 depending upon 
programs that the user has loaded into the programma- the mode of backplane communication. A backplane 
ble controller. arbitration circuit 84 supervises access to the backplane 

The final section 203 of the system controller main and resolves conflicting requests for access from the 
memory 69 is dedicated to the system support files. modules in the system. 

These files include the source program information for 50 As noted above the system controller module 16 
the function chart program* The programmable con- executes programs which control the initialization of 
troller 10 does not directly execute the function chart the system and communication with external comput- 
program. However, as will be described later, the func- era. It does not execute the user control programs, 
tion chart is employed during the programming step to 

generate data which is used to direct the operation of 55 Program Execution Processor 

the program execution modules 18. In order to permit Hie p ro gra m execution processor modules 18 store 
the subsequent editing of these programs, a source ver- and execute specific user control programs, such as 
skm of the function chart must be available for display ladder programs. One of these modules is shown sche- 
on the programming terminal. As also will be described maticaHy in FIG. 4. During this execution the modules 
hereinafter, the support files 203 contain simultaneous 60 18 read the state of the sensing devices from input image 
counters for execution of various branches of the func- table in the memory 134 of the various I/O scanner 
tion chart Although the local memory in each module modules 20, and write output data from its memory to 
contains data regarding its status, in some instances the output image tables in the I/O scanner modules, 
these memories do not have a battery to sustain them. In Data is also obtained from the system memory in the 
order to retain such volatile information after a power 65 system controller 16. 

shut-down, the status information for these modules is In order to perform these tasks, each processor mod- 
replicated in a sub-file of section 203 of the system mem- ule 18 has a set of internal buses 91-93 which are cou* 
°ry pled to the backplane 11. Specifically the processor 
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module 18 has a thirty-two bit internal data bus 92, a set 
of control lines 91 and a sixteen bit address bus 93. 
These are coupled to the data and address buses of the 
backplane 11 by respective set of tri-state, bidirectional 
transmission gates 94 and 96. The operation of these 5 
gates 94 and 96 is governed by an interbus control cir- 
cuit 95 coupled to backplane control lines 21 and the 
module control lines 91. It should be noted that both the 
internal data bus 92 and the backplane data bus 22 are 
thirty-two bits wide. Therefore, thirty-two bit data 10 
from the processor module 18 can be sent over the 
backplane as one thirty-two bit word if the recipient 
module has a thirty-two bit wide data bus. In some 
processing functions the module 18 operates on sixteen 
bit data, and in such case sixteen-bit words are applied 15 
to the backplane 11. 

The remainmg components of the processor module 
18 are connected to the internal buses 91-93. These 
internal buses are driven by a microprocessor 98, which 
is a thirty-two bit microprocessor sold commercially by 20 
Motorola, Inc. as the 68020 microprocessor. The micro- 
processor 98 has an interrupt port which is coupled to 
an interrupt interface circuit 99. This interface circuit 
receives signals from four external interrupt tines con- 



12 



buses 91-93 and executes the subsequent control pro- 
gram instructions until a stop instruction is encountered. 
At this point the bit co-processor 102 signals the micro- 
processor 98 via the control bus 91 to resume control of 
the buses and execution of the control program. Ap- 
proximately 85-90 percent of a typical control program 
of the *1adder** type may be executed by the bit co- 
processor 102. The operation of the custom Boolean 
logic bit co-processor 102 in conjunction with a micro- 
processor is fully described in above-cited copending 
U.S. patent application Ser. No. 717,221. 

The processor module 18 includes a data size ac- 
knowledge (DASACK) circuit 108. This circuit pro- 
vides a two-bit code on two of the control bus lines 
which indicates the "width** of the data on the data bus 
92. As win be described in more detail below, this data 
may be a long word consisting of thirty-two bits, a 
regular sixteen bit word, or a single eight bit byte. This 
data size information is used by the various module 
components in this data processing. 

The final component of the processor module 18 is a 
control and status circuit 110 which monitors the status 
of the processor module and provides proper control 



nected to terminals on the front of the processor module 25 ° n various ^ °* «> n ^ bus 91 to enable 



18. These external interrupt lines permit devices which 
sense high priority events, to be interfaced directly to 
the processor module for fast response. Three other 
interrupt lines on the interface circuit 99 connect to 
circuits within the processor module 18. A signal on any 30 
of these external or internal interrupt lines causes the 
microprocessor 98 to immediately interrupt normal 
program execution and execute a routine that corre- 
sponds to that interrupt line. The user may program the 
routines for the external interrupts, but the internal 35 
interrupts are serviced by dedicated interrupt service 
routines. 

The processing capability of the processor module 18 
is also supported by a floating point co-processor 100, 
and by a bit co-processor 102. The floating point co- 40 
processor 100 is commercially available from Motorola, 
Inc. as the 6881, and it is specifically designed to work 
with the 68020 microprocessor 98. The bit co-processor 
102 is a custom integrated circuit for carrying out Bool- 
ean logic operations on individual bits of the data 45 
words. Bit co-processors have been used in programma- 
ble controllers in the past to execute a set of ladder 
diagram instructions using hardwired logic as described 
in co-pending U.S. patent application Ser. No. 717,221 
filed on Mar. 28, 1985 and entitled "Programmable 50 
Controller with Function Chart Interpreter". 

The three processors 98, 100 and 102 operate in tan- 
dem to execute specific types of instructions included in 
the control program. The microprocessor 98 may begin 
execution of the control program and when it encoun- 55 
ters a floating point arithmetic function, the floating 
point co-processor 100 is enabled and the CPU 98 relin- 
quishes the internal buses 91-93 to it The floating point 
co-processor 100 takes over the processing function 
until the arithmetic operation is complete at which time 60 
the microprocessor 98 resumes program execution. If 
the control program calls for bit processing (i.e. con- 
tains an instruction in the set for the bit co-processor 



various components in a conventional manner. 

Both a read only memory (ROM) 104 and a read- 
write random access memory (RAM) 106 are con- 
nected to all three internal buses 91-93 within the pro- 
cessor module 18. The ROM 104 contains 16 bit storage 
locations for instructions and constants for the three 
processors 98, 100, and 102. The RAM 106 provides 
storage for the operands and the results of the various 
computations performed by the processor module 18. 
The control programs to be executed by the module 18 
are also contained in its RAM 106. 

The details of the RAM memory 106 are shown in 
FIG. 5. The random access memory 106 is divided into 
lower and upper banks 112 and 114. Each bank contains 
a number of storage locations, for example 196,608 
(192K) memory addresses. The memory location in 
each bank is sixteen bits wide and both banks can be 
enabled simultaneously to provide storage for thirty- 
two bit data words. As noted above the width of the 
data processed by the execution module 18 may be 
sixteen or thirty-two bits wide. In order to optimize the 
storage capacity when sixteen bit words are processed, 
a transmission gate multiplexer is incorporated into the 
random access memory 106 to allow separate sixteen bit 
words to be stored in both the upper and lower memory 
banks. Specifically, the multiplexer consists of three sets 
of tristate bidirectional transmission gates 116-118, each 
of which provides bidirectional control of sixteen data 
lines. The first set of transmission gates 116 couples the 
sixteen least significant bits (bits 0-15) of the data bus 92 
to the data terminals of the lower memory bank 112. 
Similarly, the third set of transmission gates 118 couples 
the sixteen most significant bits (bits 16-31) of the data 
bus 92 to the data terminals of the upper memory bank 
114. The second set of transmission gates 117 cross 
couples the sixteen least significant bits of the data bus 
to the data terminals of the upper memory bank 114. 
The three sets of transmission gates receive control 
signals from the DASACK 108 via control bus 91 



102), the microprocessor immediately relinquishes con- 
trol to the bit co-processor 102 by writing the address of 65 which enables the various transmission gate sets de- 
the control program instruction into a program counter pending upon the width and address of the word being 
in the bit co-processor 102. The bit coprocessor 102 sent on data bus 92. All of the address bus lines 93 go to 
then removes the microprocessor 98 from the internal each memory bank 112 and 114. 
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If thirty-two bits of data are being sent on the data bus 
92, the DASACK 108 enables the first and third sets of 
transmission gates 116 and 118. This stores the sixteen 
least significant bits in the lower memory bank 112 and 
the sixteen most significant bits of the data in the upper 
memory bank 114. When a sixteen bet word is being sent 
on the data bus 92 it may be stored in either of the 
memory banks 112 or 114. If it is to be stored in the 
lower memory bank 112, the DASACK 108 enables 
only the first set of transmission gates 116 to pass the 
data to that memory bank. To maximize the storage 
capability for sixteen bit words, the separate data may 
also be stored at the same address in the upper memory 
bank 114, in which case DASACK 108 enables only the 
second set of transmission gates 117 which couples the 
sixteen least significant bits of data to the upper memory 
bank. When sixteen bits of data are being processed, the 
third set of transmission gates 118 is never enabled. 

FIG. 9 represents the data structure of the RAM 
memory 106 for each program execution processor 
module 18. The memory 106 includes a section 310 
which contains status information regarding the mod- 
ule's operation. Each program execution processor 
module 18 also contains its own data table 312 which is 
stored in the RAM 106. The data table 312 includes 
memory locations for various counters, timers and in- 
termediate computation values. 

The largest share of the RAM memory 106 is devoted 
to storing the control programs. The actual program 
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internal buses: memory access buses 121-123, micro- 
processor buses 131-133 and I/O buses 141-143. The 
three memory buses 121-123 are connected to the back- 
plane 11 by a set of address bus gates 124 and a set of 
data bus gates 126. Both of these transmission gates are 
controlled by an inter-bus control circuit 128 which 
sends signals to the gates 124 and 126 via the memory 
control bus 121. A local random access memory, re- 
ferred to as main RAM 134, is coupled to the three 
memory buses 121-123. It stores the input image table 
for the sensor information being input to the I/O scan- 
ner 20 from the remote I/O racks 17 and it also stores 
the output image table for the output data being output 
to the remote I/O racks 17. 

FIG. 8 shows in detail the data structures stored in 
the main RAM 134 of each I/O scanner module 20. 
These data structures include an I/O image table for the 
remote sensors and actuators serviced by that module 
20. The input image table 210 represents die sensor data 
and consists of three separate sections 212-214. The first 
section 212 is the image of the actual state of the various 
sensing devices. The information relating to the inputs 
that are forced on is contained in the second section 213 
within the input image table 210. As with previous 
programmable controllers, the user may force the status 
of a given sensor to appear to be either on or off regard- 
less of its actual state. This enables the bypassing of 
faulty sensors, for example. Forced on sensors are desig- 



contents, as will be described in detail later, comprise 30 n ^J*^. t ^ a ^ one *n an address for each such input 
compiled user control programs, independent back- - - - * 

ground tasks and various interrupt routines to be pro- 
cessed by the processor modules 18. In order to prop- 
erly carry out the user control programs, support files 
containing the function chart data, called "descriptors," 
are also contained within the program area 313. 

In one mode of operation of the program execution 
processor module 18, referred to herein as the "syn- 
chronous mode", the processor module 18 periodically 



The sensors that are forced off are indicated in the 
third section 214 of the input image table 210 by a logi- 
cal zero stored for those sensors. Although by definition 
the user may write into the forced data tables 213 and 
35 214, the user is prohibited from writing into the actual 
input image table 212. During the operation of the pro- 
grammable controller, the user programs can read ei- 
ther the actual input image data from section 212 or the 
forced image of the sensor. If the forced image is read, 
copies the entire input image table from the I/O scanner 40 ^ e scanner module 20 logically OR's the actual sensor 
module 20 into its own memory 106. Space for this copy m P ut state with the forced on data from section 213, 

" ' " " " - - then that result is ANDed with the forced off data for 

that sensor from section 214. 
The output image table 211, also stored in the main 
45 RAM 134, includes the output image data table 215 
which represents the status for the output devices con- 
nected to the remote I/O racks 17 serviced by the I/O 
scanner module 20. Typically, this output data is deter- 
mined by the execution of the user control program in 
ble controller 10 to one or more remote input/output 50 the processor module 18. A second section 216 repre- 
racks 17 containing individual I/O modules 19 which senting the forced on output data and a third section 217 
interface the sensors, or input devices, and accuators, or representing the forced of? output data are also included 
output devices, to the programmable controller 10. in the output table 211. This allows the user to define a 
Each scanner module 20 periodically requests input given actuator as always being on or off regardless of 
data pertaining to the status of the input devices con- 35 the results from the execution of the user control pro- 
nected to the remote I/O racks 17 and stores it in the gram. For example, this is useful where a portion of the 
module's input image table for reading by other control- controlled equipment may have to be shut down for 
ler modules, such as the processor modules 18. The maintenance and should not be turned on by the user 
scanner module 20 also contains an image table of out- control program. The control program may read each 
put data that it receives from other controller modules, 60 of the output tables 215-217 individually. If the forcing 



of the I/O image table is provided in memory section 
314. 

Remote I/O Scanner Module 

As noted above, the I/O scanner modules gather 
input sensor data for use by the program execution 
processor modules 18. Referring to FIG. U 2 and 6, a 
remote I/O scanner module 20 couples the programma- 



such as the processor modules 18. At regular intervals 
the updated output data in the scanner module's output 
image table is transferred to the respective remote in- 
put/output racks 17 to control the various actuators 
connected to these racks. 

Referring specifically to FIG. 6, each remote I/O 
scanner module 20 connects to the three backplane 
buses 21-23. The I/O scanner 20 contains three sets of 



of the output states is disabled the data sent to the re- 
mote I/O racks 17 for activating or deactivating the 
various controlled devices is obtained from the output 
image table 215. If output state forcing is enabled then 
65 the data sent to the remote I/O racks 17 is a logical 
combination of the three output tables 215-217 using 
Boolean logic that is identical to the combination of the 
three input tables 212-214 described above. 
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Referring still to FIG. 8, the data structure in the 
main RAM 134 of the I/O scanner module 20 also in- 
cludes a block 218 that contains data regarding the 
status of the communication adapter in each of the re- 
mote I/O racks 17 serviced by the module 20. This data 5 
is used during the transfer of information over the I/O 
links 15 with those remote I/O racks. 

Although the state of most of the sensor and operat- 
ing devices may be represented by a single binary bit, 
certain devices, such as position sensors and analog 10 
devices, produce or require information that comprises 
a plurality of digital words. These data may be transmit- 
ted to or from the remote I/O rack 17 into the I/O 
scanner module 20 as a large block of data. Memory 
section 219 in the main RAM 134 contains information 15 
necessary to control such transfers of blocks of data and 
a companion section 220 provides a memory area for 
the storage of the actual blocks of data. For a detailed 
description of this block transfer reference is made to 
U.S. Pat. No. 4,413,319 entitled "Programmable Con- 20 
trotter for Executing Block Transfer with Remote I/O 
Interface Racks". 

Referring again to FIG. 6, the inter-bus control cir- 
cuit 128 also sends control signals to an I/O data arbitra- 
tion circuit 130 which resolves conflicting requests for 25 
access to the memory buses 121-123 from the backplane 
11 and the microprocessor buses 131-133. Two sets of 
transmission gates, address gates 136 and bi-directional 
data gates 138, interconnect the memory buses 121-123 
to the microprocessor buses 131-133 and receive con- 30 
trol signals from the I/O data arbitration circuit 130 via 
the memory control bus 121. The operation of the re- 
mote I/O scanner 20 is controlled by an eight-bit micro- 
processor 140 which is connected to three microproces- 
sor buses 131-133. Microprocessor 140 is commercially 35 
available from Zilog, Inc. as the Z80 and it is the only 
device which is directly connected to the microproces- 
sor buses 131-133, other than the sets of transmission 
gates 1361, 130, 144 and 146 and the I/O data arbitration 
circuit 130. 40 

A set of address gates 144 interconnects the micro- 
processor address bus 133 to the I/O address bus 143 
and a set of bi-directional gates 146 interconnect the 
data buses 132 and 142. Both sets of tri-state gates 144 
and 146 receive control signals from the I/O data arbi- 45 
tratkm circuit 130 via the microprocessor control bus 
131. The microprocessor control bus 131 is directly 
coupled to the I/O control bus 141. 

The I/O control buses 141-143 interconnect the de- 
vices which interface the I/O scanner module 20 to the 50 
remote I/O racks 17. These include a serial I/O inter- 
face circuit 148 which provides two synchronous serial 
input/output channels 150 and 151, each of which has 
its own cable driver/receiver circuit 152 and 153 re- 
spectively. A counter/timer circuit (CTC) 154 and a 55 
direct memory access (DMA) controller 156 are also 
connected to the I/O buses 141-143. The I/O bus sec- 
tion of the scanner 20 also includes a random access 
memory, indicated as I/O RAM 158 for temporary 
storage of input and output data communicated over 60 
I/O serial links 15. A read-only memory (ROM) 160 is 
also connected to the I/O buses 141-143 and it contains 
the programs which are executed by the microproces- 
sor 140 to carry out the functions of the scanner module 
20. An address decode circuit 162 is also connected to 65 
the address and control buses in the I/O section of the 
scanner module 20 to interpret the addresses generated 
by the microprocessor 140 and produce the proper 



enabling and control signals on the lines of control buses 
131 and 141. 

The operation of the remote I/O scanner modules 20 
is described in a subsequent section on data acquisition 
and transfer. 

Controller Operation 

The novel architecture of the present programmable 
controller 10 dictates that it functions in a unique man- 
ner. The areas in which the present system operates 
differently than previous programmable controllers 
include system initialization, I/O data acquisition and 
transfer, and intermodule communication. However, 
the most significant difference with respect to this con- 
troller lies in the formulation and execution of the user 
control programs. Each of these unique functions will 
be described in detail. 

System Initialization 

During system power-up, the system controller 16 
supervises the configuration of the system and various 
other tasks as shown in the flowchart of FIG. 13. The 
first phase 450 of power-up occurs immediately after 
the system reset signal terminates. During this interval 
no module is allowed on the backplane 11 and the vari- 
ous modules perform local tests of their own memory 
and other subsystems. When each module is finished, it 
releases a common ready line of the backplane control 
bus 21. When the last module has completed its internal 
tests the signal on the ready line is true. This signals the 
system controller 16 to make a transition into the next 
power-up phase. 

During the second phase 451, the system controller 
16 goes on to the backplane 11 and requests the module 
in each slot of the rack 12 to identify itself and provide 
the system controller 16 with various information re- 
garding the module, such as the module type, and ad- 
dresses for various interrupts and data pointers which 
are stored in the system memory 69. Based on the infor- 
mation received from each module, the system control- 
ler 16 verifies that the system is properly configured. 
For example, if there is more than one program execu- 
tion processor module 18 on the system, the system 
controller 16 verifies that each one has a unique module 
thumb wheel designation and that two of them do not 
have the same designation. 

In the next phase 452, the system controller module 
16 stores the backplane communication parameters in 
preassigned memory locations in each module. These 
parameters instruct the modules how to communicate 
over the backplane, Once a module knows how to com- 
municate via the backplane 11 it loads its memory ad- 
dress pointers into memory locations in the system 
memory 69 of the system controller 16. These address 
pointers are used by other modules to a cc es s the data in 
the module or issue instruction to h\ For example each 
module loads the addresses of its interrupts into the 
system status section 201 of the System Memory (FIG. 
7). In the course of this phase, the various functional 
modules may communicate only with the system con- 
troller 16, not with any other type of module. Referring 
again to FIG. 13, the next phase 453 of the initialization 
allows the modules to talk with each other and ex- 
change any necessary data. At the completion of this 
phase, the programmable controller 10 at step 454 
makes a normal transition into the user defined start-up 
mode, typically either "program** or "run." 
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i>ro^mS ^^^^J 0 ^^ operation: processor 140 signal, the I/O data arbitration circuit 
propjunmmg, program ran and fault mode, as deter- 130 to disconnect the interconnection of the internal 
mmed by the system controller module 16. Each of buses. 

m^^r^Z^^ 1 fat °J 1 Umbcr .°. f . i ? t ? raal At other periodic intervals, the remote I/O scanner 
Dret^lLrnT™^^ m0de , h8S 30 mm " 1 m *> at 5 modulc 20 sends output state data to the remote I/O 
{taf^S Tf a! — P ,^ r to P™*™ « ecu " This process is similar to that described imme- 

£^l^f^r° the remote I/O scanner modules 20 diately above with respect to the input status data. The 
^ ?? m ?f ""P 8 ??™ I /0 ^ 17 «nd microprocessor 140 requests the interconnecti^of the 
create an initial mput image table 210. Following the internal module bus« 121-123, 131-133 a^d 141-143 

w&^f 8 "' * PC ° gr ^ 'JT™ fa Carricd 004 durin * «» Once the interconnection biade the U« 
which one or more of the user control programs are table data in main RAM 134 is transferred to thH/O 

O^^^T^l^ °T at ^ 211 RAM 158. The bus mterconneSTi™ dLi" 
E^fi.^ 1 ^5* Pf"^" modcs ^ ve «»■ completed nected. The output data in I/O RAM 158 is systemati- 

bel^S ^ t2? TS^* 210 tSi M1 ^ to I/O racks 17 overserialS^ 

been created, the various outputs are enabled and the 15 to activate or deactivate the operatina devices the 
run mode commences formal execution of the user con- controlled equipment °P cratln g dcvlccs ° n *e 

^'Pf??™™; , - r . As noted above, the I/O RAM 158 is used to store the 

t .i"°^ CT to .lT plmn formulation and execution of data that is sent and received over the serial links 15 
die user control program, one must understand how During the communication proceT n^nr^sor 

n^le^n^» W ^^ Wittothepr0 « n,m - 20 140 ^ «« have to acc^tnTntTl^Zg^e 
controller 10. stored in main RAM 134. This freeing of the mam RAM 

Data Acquisition and Transfer 134 60111 coimnunication tasks as well as the I/O mod- 

.„ ct^c , -, . "le's separate internal bus configuration permits other 

JJSR* FI 9 S - * and* periodically each I/O modules on the backplane 11, such as the^stem con- 

e^Tf^^X^ ^ ?° m £? nnected to 25 *«>Uer 16 and processor modules 18, to 0^^^, 

Z£££L ?" tr0 !^! r T°^,'? ck3 This acquisi- the I/O image table data in the main RAM 134 ThS 

ton of data is suuuar to the I/O scans performed by direct access from the backplane does not Evolve th^ 

^^n m U ol P ^h N VO^m^ ».2K 30 17^ ~* *° ™ bracks 

££LEES? J^* 17 to ^ input data When the system controller 16 or one of the proces- 

reg«dmgthe status of sensmg devices connected to the sor module, 18 desires to read the status of a giv« fa^i 

With „f ~ ,„ mr- * .v • , . , device, it requests access to the backplane buses 21-23 

t**£jE5ZE£?2h.* » >tlK T g ° fdatafrom » order to interrogate the I/O scanner module 20 that 
lot MO^I^ii^h. T /^T? Cd .L U ' b ? micT °P rOCCS - 35 «^ves the input data from that particular sensor 

sor 140 instructing the I/O data arbitration circuit 130 Upon being granted access to the baclcolane lithe 

to enable tranamssion gates 144 and 146. This couples processor module 18 oTs^em c^tr^cfl^dresses 

Ml STa^1£ ^TJf UU f u 1/0 bu8CS the appropriate I/O scann« mo^I LTonTS 
SjTvJ^ ^ connectlon of thc buses is com- this addressing, the interbus access controller 128 
£££ ^K mCr ° Pr ? C, ^f I4 °. Sequcntiall y ^ com - «> within the respective I/O scann^odSe M rZJ£ 
d^e^«2»n^?1 UO ^.T, SI ° «■■"»"» an access req^tsignal over a line of the c^nttoToTa 
re^oS JfLflV^ ^L^SSf to C ° m , mands ^ of b^kptane 11. The interbus access controUer then 
^^n^niLTT^ m P ut J data . to *gnals *e I/O data arbitration circuit 130 that a reque^ 

P^^^reTt I/O R^^T^ ^ ^ •** ^ t0 L acCeSS main RAM 134 has been received from an- 
poraruy stored in I/O RAM 158. The communication 45 other module. At the appropriate time when the inter- 

r?T£L^?£ f^l^ 1 " ^ 1/0 »»» »«»ory buses 121-123 are avaUaSe to b?co^ed 

"nLu^ preVX>nS prOBrammab,c to *»»? backplane buses 21-23, the I/O data arbitration 

A , . . . ^. .... . circuit 130 signals the interbus access controller 128 that 

fe^lt fSi th™^^ ^^ CTed u mpUt ««»*• U tnms- it may connect the backplane and memory busesT 
ferred from the I/O RAM 158 to the input image table 50 gether via transmission gates 124 and 126. The comnV 
conu^^thm the main RAM 134. This transfer is Son of this connecti^ Aef a^owTe^"7the 
2£TS£t£ *L arhS"^ S T ^ ^"^^ inter buS circuit 128 to the requesting moduie 

meloS a^c^m^ l^f ^1 ™f of ^ ^P 1 ™ control bus 21. The other 

.^f^U ^ "?: 12 fi coprocessor buses module then reads from or writes data into the I/O data 
Dhrne^l^ J£L VrX 3 togethCr - back- 55 image table in the main RAM 134. The data ttansm£ 

m 123 ,L T /r^"f. ^Lk! mcmor y,^ess buses sion may be a single data word or a block of words. The 

II?' • V ■ "brtwoon circuit 130 wiO issue requesting module holds control of the backnlane 11 
m^ ^13^13^ m b a r 4 ,£\ and 131 to rT 5" f ° 8 f the requested da te blT.ranslu^ to i 
c^S^l^^Si^^ "^."spoa^tothe from the I/O scanner 20. When the access is finished the 

transm«Mon gates interconnect the 60 inter-bus control circuit 128 is signaled viaXback* 
^L^L, ?L The I/O data arbitration plane control bus 21 and the connection to tte balk- 
circuit 130 then sends an acknowledge signal to the plane 11 is disconnected. 

^T^S!T 0r "^^^S that the connection has As is seen, the configuration of the I/O scanner mod- 
^^-Y^i^^, 8 thc t acl e nowled Se signal, the ule 20 permits other modules connected ^tt^back- 

R^S^tht^^ t 1 "-^^ ^ V ? <S J*" to ^ e «««ct access to theTo1can»e7 S S, 
RAM 158 and the mam RAM 134. The input data is RAM 134 without the intervention of the scannert 

^ ^*'^ t t .^* e f 16 212 (FIG. 8) of main microprocessor 140. This allows tte nucroSoSS 
RAM 134. When the transfer is complete the micro- devote its attention to controlling the gathering^ sen- 
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sor data and transmitting output commands to the 
equipment actuators. 

The access to the I/O image table data by each pro- 
gram execution processor 18 may be on an "as needed** 
basis or periodically an image of the entire I/O data 
table may be read by the processors from the scanner 
modules 20. In the "as needed** mode whenever the user 
controller program being executed by the processor 
module 18 requires the evaluation of a sensor status, the 
processor module 18 gains access to the backplane buses 
21-23 and requests data from that sensor via the appro- 
priate I/O scanner 20. This mode is referred to as "asyn- 
chronous** in that the access to the I/O scanner module 
20 is on an "as needed" basis and not a periodic basis 
which is synchronized to the execution of the user pro- 
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An alternative method of accessing the sensor input 
data from the I/O scanner modules 20 is in a synchro- 
nous, or periodic fashion. At a given point within the 



scheme described above whereby the highest priority 
level for backplane access passes from one module to 
the next in rack slot number order. Initially, the module 
in the leftmost rack slot has the highest priority and the 
5 priority level decreases with each slot to the right. At 
this time, if a conflict exists between the modules in the 
second, fourth and sixth slots, the module in the second 
slot gains access. When a module is granted access, the 
priority levels shift one module slot to the right. Now 
10 the second module has the highest priority and the 
module in the first slot has the lowest priority. Then, if 
the modules in the first, third and eighth slots simulta- 
neously seek access to the backplane 11, the third mod- 
ule gets access as it has the highest priority among the 
15 three. Then the eighth module has access and finally the 
first module is granted access the backplane 11. The 
priority keeps shifting whenever any one of the modules 
accesses the backplane 11. After the module in the last 
slot has had the highest priority level, the highest level 



execution of the user control program by the program 20 rotates back to the module in the first, or leftmost, slot 

execution processor 18, the input image table 210 from The system controller memory 69 may also be di- 

each I/O scanner 20 is read and copied into the local rectly addressed by other modules on the backplane 11 

memory 106 within the processor module 18. For exam- so that they may gain access to system data. During the 

pie, just prior to the commencement of each pass execution of the user control program, the main func- 

through the user control program, the processor mod- 23 tkms performed by the system controller 16 relate to the 

nle 18 gains access to the backplane 11 and interrogates handling and execution of communications on the local 

each of the I/O scanner modules 20 copying each scan- area network 28 and the programming terminal 24. 

ner*s input image table 210 into the processor module A module requiring data from the system controller 

memory 106. This ensures that the input data being used module 16 or an I/O scanner module 20 is able to access 

during the subsequent pass through the user program 30 the main RAM's in these modules directly via the back- 

will remain constant and that each rung will be evalu- plane 11. However, when a module desires to send a 

ated using the same sensor status. The choice of which block of data or a command to another module in the 

mode of operation to use is left to the operator/pro- rack 12, a different technique for communication be- 

grammer and depends upon the characteristics of the tween the two modules must be employed, 
particular function chart and user control programs 35 
being executed. Unless otherwise specified by the oper- 
ator, the system defaults into the asynchronous mode. 

Referring particularly to FIGS. 2 and 8, the output 
image table 211 in each I/O scanner module 20 is up- 



Inter-module Communication 



As indicated above, I/O data may be transferred 
directly from one module on the backplane 11 to an- 
other module. This direct transfer is possible when data 



dated immediately upon a change of the status of an 40 is being read from or written to very specific memory 



data structures, such as an I/O image table, in the other 
module. However, in the present multiprocessor sys- 
tem, other forms of messages which do not reside in 
predefined data structures are often conveyed between 
the modules. A more general purpose inter-module 
communication protocol is required for such messages. 
This process is re f erred to herein as sending "mail". 

Within each module that is capable of receiving mail 
is a set of mailboxes as illustrated in FIG. 14. The set 



actuator connected to one of the remote I/O racks for 
that module. Specifically, when the user's program calls 
for a change in status of a controlled actuator, the pro- 
gram execution processor 18 gains access to the I/O 
scanner module 20, as described above, and reads from 45 
the I/O scanner RAM 134 the output image table word 
that contains the bit or bits to be changed. Once the 
processor module 18 receives a copy of that output 

image table word, it changes the corresponding portion 

and writes the altered word back into the output image 50 comprises sections for "priority** and "regular'' mail! 
table 211 of the same scanner module 20. During this Each section has sixteen mailboxes, each consisting of a 
reading and writi ng of the I/O scanner module's RAM two word storage location. These sixteen mailboxes 
134, the program execution processor module 18 retains allow the exchange of messages with modules in the 
control of the backplane buses 21-23 so that no other eight slots of the main programmable controller rack 12 
module may read or alter the output image table 211 of 55 and with eight modules in an auxiliary rack (not 
that scanner module 20 while the processor module 18 shown). Each of the mailboxes in each section corre- 
ts performing its output function. This ensures that the sponds to one of the slots in the two racks. During the 
output image table 211 is not changed or that another configuration process, each module writes the address 
execution module uses stale data. It is, however, up to of the top of its mailbox set into the area of the system 
the user, through the control programs, to ensure that a 60 status file 201 (FIG. 7) which contains data for that 



given controlled device is only being activated or deac- 
tivated by one processor module 18 at a time. 

Once a module has relinquished its control of the 
backplane 11 another module in the system may access 
the backplane. If more than one module seeks such 
access at the same time, the backplane arbitration circuit 
84 in the system controller 16 resolves the conflict. The 
arbitration circuit 84 implements the rotating priority 



module. The address of each module's mailbox inter- 
rupt is also stored in the system status portion 201 of the 
main system memory 69. 
A "priority mail** message forms an urgent command 
65 which the recipient module is to immediately carry ouL 
The command is either executed within the mail han- 
dling task which detects the receipt of the command, or 
it is passed to a destination task for processing. The 



Command 




Code 


Command Description 


1H 


Mailbox Command Acknowledgment 


2H 


Begin Function Chart Step Execution 


3H 


Begin Interrupt Routine Execution 


4H 


Change System Mode 


5H 


Change Power Up Phase 


6H 


End Power Up 


7H 


Hah Active Syttem Operation 
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priority mail message consists of two sixteen bit words module loads the source module's mailbox slot with 
as shown in FIG. 12A. The first bit of the first word is zeroes preparing it to receive another message, 
a zero designating the message as priority mail The "Regular mail" typically is used for transferring more 
next seven bit field (CMD) of the first word contains the than two words of data, although command messages 
coded form of the command to be executed which is 5 described above also may be sent to these mailbox slots, 
selected from the following list: For example, regular mail is used during system start-up 

to send configuration data to each module. It is also 
used during normal operations to send messages that do 
not require immediate response or action. Still referring 
10 to FIG. 14, when a source module 230 has several 
words of data to transfer, it assembles the data into a 
block 236 in its local memory 238. It then stores, in 
another block of memory 240, all the parameters neces- 
sary for the destination module to access the data in the 
15 source module's memory and acknowledge access to 
the source module 230. These parameters have a prede- 
fined format similar to that used in previous program? 
The remaining bits of the first word are not used by mable controllers and include the address of the data 
every command. The second word contains a pointer to message, its length, the destination module's task which 
a location within the recipient module local memory 20 will use the data, and other information necessary to 
containing data for executing the command. For exam- transfer the data. 

pie, a priority mail message is sent by one program The two word message is then formulated in the 
execution processor module 18 to inform another such source module's memory 238. The format of the mes- 
module to commence the execution of a specific user fage 13 shown in FIG. 12B. The first bit of the first word 
program for a given function chart step. In this instance 25 *s a binary one designating this as a regular mail mes- 
the command (CMD) in the first word is **2H" telling ^ e next three bits are all zeroes indicating a data 

the recipient module to begin a new function chart step. block type message as opposed to a command. The 
The second word is an offset pointer for the table con- remaining twelve bits of the first word and all sixteen 
taming the address in the recipient's memory that con- ***** oftnc second word contain the beginning address of 
tains information about the step and its control pro- 30 t * lc transfer parameters within the source module, 
gram. This information is passed to the function chart Tn e source module 230 then notifies its mail handling 
interpreter program in the recipient module. t 38 ^ to send the regular mail message. As with priority 

Referring to FIGS. 12A and 14, in order to send mail mai1, task accesses the backplane 11 and tests its 
the source module 230 first formulates the two word regular mailbox slot in the recipient module's memory 
message in its memory. The transfer of the message is 35 *° in *ke sure that it is empty. When the first word of the 
controlled by a mail handling task in the module, see mailbox 8,01 m **** destination module is all zeroes, the 
also the flowchart of FIG. 15. The priority mail transfer ^ word rc £ular message is written into the slot. Once 
process is initiated by the source module 230 accessing . mailbox ^ m recipient module is loaded, the 
the system controller main RAM 69 via the backplane mtcr ™Pt word is sent to the recipient module's mail 
11 to obtain the addresses of the mail interrupt and the 40 m ^f u P t addesss. ^ , ^ ^. . 

top of the set of mailboxes 233 in the recipient module The recipient module 232 upon being interrupted 
232 at step 46a These addresses are stored in the system J? maUbox f fo ' ^ J^*?^ Un ^ e Parity 

status section 201 of the system controller's main RAM ' !Wp ? t mo ^^ does not immediately 

69 (FIG. 7). The source module 230 knows the index ^ S~ k * "3?^ Hi' P ^** A %^ en ?? rma 
fromthetcpoftbensailboxset^ 45 queue for handling when time permits. The handling of 

mailbox sloi in the recipient module. The mail SSng «^^ f 1 * to WCf ** to 

task in the source module 230 then again seeks access to control r^ogram. When the recipe 

i^t module memory 234 If tbe ^ word £ s^oTo!^ 

^r^^t^r^^lf ?! CV1 T * ^ acquisition process described above. After copyteg 

fi m ^"Sf 0 *-. ^J^? 0 *** a P*™* 1 of the data the recipient module 232 sends an acknowledge 

tome and tnes again. When the first mailbox word is 55 ment via regulaY mail to the source module 230 ^fd 

*™° d » C ^ tam j" zcroes ' sourcc 230 zeroes out the regular mailbox slot. The data then may 

writes the two word message containing the command be processed by the recipient module 232. 

^ ntCr J mt0 J to ** m "cip^t With an understanding as to how data and commands 
mailbox list at step ^464 and sends an interrupt word to are sent between modules, the execution of the different 
the recipient module s mailbox interrupt address at step 60 types of programs can be described. 
465. 

The mail handling task in the recipient module 232 in Program Formulation and Execution 

resrxmse to the mterrupt reads the priori The present programmable controller may execute 

the entry is a command to start a new function chart several general types of programs, such as a machine 
step^anentry is made m the queue for the function chart 65 operation program, independent background programs, 
mterpreter program. An acknowledgment is then re- interrupt subroutines and fault subroutines. The ma- 
turned to the source module 230 via an entry in its chine operation program is developed by the user of the 
mailbox set and an interrupt. At this time the recipient programmable controller to apply it to his particular 
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machine or process. For very complex processes, the 
m a chin e operation program is defined by a sequential 
function chart showing each major step of the process. 
A separate user control program is developed to per- 
form the functions of each step. These user control 
programs may comprise ladder diagram programs, as 
well as control programs written in higher level lan- 
guages. Because the preferred embodiment executes 
compiled versions of the user control programs, assem- 
bly language and high level languages, such as BASIC, 
may be employed to generate the source code for the 
user control program. The user control programs are 
ass i g n ed for execution to the different processor mod- 
ules. However, the present programmable controller 
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or 50 percent of the processing time of each processor 
module 18 for handling these tasks* The operating sys- 
tem will time-slice between the various operations of 
this type during the time allocated for them* When the 
allocated time expires the processing of these tasks is 
suspended until the occurrence of another interval for 
their operation. In addition, if the processor module is 
not currently executing a control program, the entire 
processing time will be devoted to the background tasks 
as necessary. 

The remaining processing time is allotted to the exe- 
cution of the machine operation program. As this task is 
usually time critical, the amount of time designated for 
background task processing generally is a function of 



provides the coordination of this parallel processing in 15 how much time must remain for the machine operation 
accordance with the single machine operation program. program. By carefully selecting the amount of proces- 
^ The independent background tasks are user programs sor time devoted to the background tasks, the operator 
that are subordinate in execution to control programs can cause an execution pass through the machine opera- 
and may be used for lengthy non-time critical opera- tion program to occur at regular intervals, which may 
toons such as data acquisition from other computers and 20 be desireable in certain machine control applications, 
report generation. Interrupt routines allow high priority The machine operation program continues running 
operations to be executed upon the occurrence of a until a timed interrupt signals the start of a background 
given event, while fault routines permit a graceful re- task interval. 

covery from a detected error condition in either the The present programmable controller provides an 
programmable controller 10 or the equipment being 25 improved system for executing the machine operation 



control programs, therefore, these programs will be 
described in detail. A function chart program defines 
the overall control process as a sequence of steps and 
provides the mechanism for coordinating the simulta- 
neous execution of different parts of a single machine 
operation program in parallel by multiple program exe- 
cution processor modules. As per convention each step 
is followed by a transition condition which specifies 
when the step is completed. A separate user control 



controlled. 

Bach processor module 18 has its own operating 
system which runs completely independent of the other 
modules 18 in the system and which is unaffected by the 
processing of those other modules. Routines on the 30 
same processor module 18 share the resources of that 
module with the operating system deciding how much 
processing time is allocated to each one of the simulta- 
neously running routines. ^ 

In order to provide orderly execution of the various 35 program, such as a ladder programTis written" for each 
types of programs by a processor module, a priority step and transition of the function chart, 
system is established. The highest priority level consists The machine operation programs are written on the 

of various interrupt routines that are so time critical that intelligent terminal 24 or on a personal computer or 
their execution may never be interrupted. The next host computer connected via the local area network 28. 
level includes all other interrupts which are normally 40 These progpamniing devices contain the necessary soft- 
run to completion except when a top priority interrupt ware so that the programmer can author the function 
or fault occurs. chart and the user control programs. The terminal or 

Interrupt routines comprise processor input inter- programming computer also compiles each user control 
rupta and selectable timed interrupts. Processor input program into ma^w* language instructions for direct 
interrupts are started by an externally generated input 45 execution by one of the processor modules 18. If a lad- 



der program is used as the user defined control pro- 
gram, the technique for authoring it is the same as for 
conventional programmable controllers. The only dif- 
ference is the compilation of the completed program. 

The authoring of the function chart is different for 
the present programmable controller than for previous 
ones. The function chart is still graphically constructed 
on the screen of the prograinming terminal 24 or the 
programming computer. The software and techniques 



and are used for high priority routines which are in- 
tended to be executed only upon the occurrence of a 
specific input condition. To accommodate the proces- 
sor input interrupts, each processor module 18 has an 
interrupt interface 99 (FIG. 4) which receives and han- 50 
dies interrupt signals from external devices. The select- 
able timed interrupt routines are started at regular speci- 
fied intervals by the system's real time clock. A priority 

is associated with each interrupt and if more than one 0 r _ w ^ ^„„. 

interrupt is pending, the one with the higher priority 55 for doing this are similar to that practiced with conven- 
will be executed first. tional programmable controllers. However, unlike pre- 

The execution of the various other program types is vious controllers, the function chart does not produce 
carried out by grouping the programs and allocating a executable code but rather generates a set of descriptor 
portion of the processing time to each group. A given files which may be thought of as directives that instruct 
amount of the execution time may be designated by the 60 the programmable controller which user control pro- 
operator during system configuration for the execution gram to execute, when to do so and which processor 
of non-time critical operations; such as background module to use. 

tasks, handling of regular inter-module messages, com- An example of a function chart is shown in FIG. 10. 
municating with other computers and miscellaneous Each processing step of the function chart is designated 
tasks. These low priority operations will be collectively 65 by a rectangle such as box 403, and each transition from 
referred to as "background tasks,** although it is under- one step to another is designated by a horizontal line, 
stood that background tasks are but one type of these such as line 402. The initial step of the function chart is 
operations. Typically, the operator may select 20, 30, 40 defined by a double rectangular box as illustrated by 
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box 400. Although the initial step 400 in the FIG. 10 
function chart is at the top of the chart, it may be almost 
anywhere in the chart, with the exception of within a 
simultaneous construct, as will become apparent. As 
with function charts for previous programmable con- 
trollers, step 400 includes the name of a file in memory 
(eg. FILE 1) that contains the user control program to 
be executed for that step. Unlike previous function 
charts, the box 400 also contains an indication (PI, P2, 
etc.) of the processor module 18, that will execute the 
user control program for that particular function chart 
step. The present programmable controller 10 has two 
processor modules 10, which are designated PI and P2, 
although additional processor modules can be inserted 
in the rack 12. The processor module 18 assigned to the 
initial step and the user control program file number are 
eventually stored in the system status file 201 of the 
system controller's memory (FIG. 7) so that the pro- 
grammable controller knows where to begin executing 
the machine operation 

The user control diagram program for step 400 for 
example is executed by the first processor module PI 
which repeatedly executes the program until a pro- 
grammed condition is met That condition is repre- 
sented by a transition (such as at 402) immediately 
below the box (400) in the function chart. Typically the 
transition 402 is defined by a single rung ladder pro- 
gram, which is executed on the same processor module, 
eg. PI, as the associated step. The assignment of the 
processor module for the transitions is automatically 
made by the function chart editing program. If this rung 
is found to be true, the execution of the user control 
program for step 400 ceases and the program execution 
advances to the next function chart step 403. The por- 
tion of the function chart in FIG. 10 containing step 
400, transition 402 and step 403 is typically referred to 
as a "sequence" construct in that each step sequentially 
follows the other. 

Following step 403 are three separate program 
branches, only one of which will be selected for execu- 
tion depending upon the corresponding transition con- 
dition. This choice of one of many branches is referred 
to as a "selection" construct. The first branch includes 
an initial transition 404 that is defined by the user con- 



26 



ditions of the initial transitions 404-406 in each branch 
are sequentially examined. The first initial transition 
which is found to be true determines which of the 
branches will then be executed. For example, if the 
5 condition defined by the user control program in file 13, 
transition 405, becomes true first then only the middle 
branch having step 408 will be executed. The comple- 
tion of the user control program for step 408 is indicated 
by the termination transition 411 contained in file 16. 
10 When that transition becomes true, the program trans- 
fers to step 413 contained in file 6 which is executed on 
the second processor P2. 

Once step 413 is completed as indicated by transition 
414 the function chart enters what is referred to herein 
15 as a "simultaneous" construct A simultaneous con- 
struct comprises a plurality of function chart branches 
each containing at least one step. As the name implies 
the branches are executed simultaneously. In this case 
three processor steps 415-417 are to be executed in 
20 unison. The first step 415 comprises the control pro- 
gram stored in file 7 which is to be executed on the first 
processor module PI. The program for the second 
branch step 416 is contained in file 8 and is to be exe- 
cuted on the first processor module PI, while the third 
25 branch step 417 which is represented by the control 
program in file 9 is assigned to the second processor 
module P2. Because files 7 and 8 are both assigned for 
execution by the first processor module PI, the user 
control program contained in each of the files will be 
30 concatenated (i.e. strung together to run sequentially). 
This concatenation is similar to that practiced in present 
programmable controllers. However, whereas previous 
programmable controllers would have to concatenate 
all of the simultaneous construct files, including file 9, 
35 the present system has assigned file 9 for execution by 
the second processor module P2 and the remaining two 
files 7 and 8 for execution by the first processor PI. If 
the programmable controller 10 contained three sepa- 
rate processor modules 18, the function chart step for 
-40 each branch could be assigned for execution by a sepa- 
rate one of the modules. 

As an example, the simultaneous construct portion of 
the function diagram in FIG. 10 could control a manu- 
facturing process where the user control program in file 



trol program contained in file 12 and processing step 45 7 controls the manufacturing process by reading various 



407 defined by the user control program contained in 
file 3. Step 407 is followed by a termination transition 
condition 410 that is contained in file 15. Similarly, the 
middle branch contains an initial transition 405, a pro- 
cessing step 408 followed by a termination transition 50 
411. The third and final branch of the selection con- 
struct consists of initial transition 406, main processing 
step 409 and a termination transition 412. Following 
transition 412 is a GOTO statement which when exe- 
cuted causes the program to jump to the point where 55 
the designated label appears. In this case the program 
jumps to the label "BRAD" before step 419 at the bot- 
tom of the function chart All of the initial branch tran- 
sition files 12, 13 and 14 are stored on and executed by 
the same processor module (PI) as the previous func- 60 
tion chart step (403). It should be noted that since only 
one of the three branches of the selection construct is 
executed, they all may be processed by a single proces- 
sor module 18, in this case the first processor module 
PI. Although, different branches could be designated 65 
for execution by different processor modules 18. 

Upon the completion of the previous function chart 
step 403, which preceeds a selection construct, the con- 



sensors and in response thereto activates or deactivates 
various pieces of production equipment File 8 may 
consist of a control program that displays on the termi- 
nal 24 the status of the process being controlled by the 
program in File 7. In this case, the user control program 
in File 9 may monitor other sensors and activate alarms 
should any of these sensors indicate that given manufac- 
turing errors have occurred. 

The transition out of the simultaneous construct sec- 
tion is indicated by what is referred to herein as a "con- 
verge** construct This construct contains a single tran- 
sition step 418 in which the user control program in file 
19 is executed on the second processor module P2 fol- 
lowing each scan of the user control program in file 9. 
This converge construct transition is automatically as- 
signed by the programming process to the same proces- 
sor (eg. P2) as the rightmost simultaneous branch. 
When the transition 418 is true, the execution of each 
branch of the simultaneous construct ceases at the end 
of their current program scan. As noted above with 
respect to the data structure of the system controller 16 
in FIG. 7, the system support file 203 contains a mem- 
ory area for the step counters of the simultaneous por- 
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tions of the function diagram. One of these counters is 
loaded upon entry into the simultaneous section with 
the number of simultaneous processing steps in the con- 
struct After the transition condition 418 is satisfied, this 
counter is decremented as each step 415-417 completes 5 
its program scan and comes to a halt. When the counter 
reaches zero, all of the simultaneous steps are com- 
pleted and the transition to the next steps 419 and 421 
following the converge construct can occur. 

In prior art systems, the three function chart steps 10 
415-417 (FIG. 10), which were simultaneously exe- 
cuted, had to be concatenated for execution by a single 
processor and the execution of a given user control 
program occurred only once per pass through all three 
programs. Therefore, with respect to the above exam- 15 
pie if the control program in File 9 was an alarm func- 
tion, it would only be scanned at the completion of the 
scan of the control programs in Files 7 and 8. Whereas 
in the present multiple processor system winch utilizes 
parallel processing, the user control program for the 20 
alarm function is repeatedly processed by its own pro- 
cessor module P2 without the intervention of other user 
control programs being concatenated with it This pro- 
vides more frequent monitoring of time-critical condi- 
tions than is possible in a single processor system. 25 

The graphical representation of the function chart 
per se is not executed by the programmable controller. 
It is used, however, by the programming terminal soft- 
ware to assemble a set of data files for each of the pro- 
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cessor modules 18. Specifically, the function chart is 30 function chart 



larly useful in program debugging. The descriptor 430 
also identifies the next descriptor file to be used upon 
the completion of the current descriptor file and the 
processor module 18 in which it is stored. In this exam- 
ple the first descriptor 430 designates "Descriptor 2" as 
the next descriptor file which is assigned for execution 
by the first processor module PI. 

The second descriptor file 432 on FIG- 11A is gener- 
ated from the selection construct of the function chart 
in FIG. 10. The first word in the second descriptor 432 
indicates that it is a selection type and that file number 
2 contains the user control program for this step. The 
remainder of the descriptor 2 contains an array of tran- 
sitions and their corresponding next decriptor file num- 
ber and processor. For example, as shown in the func- 
tion chart of FIG. 10, the first element of the array 
indicates transition file 12 and its next descriptor is de- 
scriptor 3; the second element of the array indicates 
transition file 13 and next descriptor 4; and the final 
entry in the array indicates transition file 14 followed by 
the next descriptor 5. 

The descriptors for the three selection branches (de- 
scriptors 3, 4, and 5) are of the sequence type and have 
the same format as the first descriptor 430. The sixth 
descriptor is designated as the next descriptor file num- 
ber in both descriptors 3 and 4. However, the next de- 
scriptor file number in the descriptor 5 for the third 
selection branch is the tenth descriptor for step 419 
because of the function chart GOTO statement in the 



reduced to a series of descriptor files that describe the 
operations of a portion of the function chart Each de- 
scriptor contains data which identifies the user control 
program for a step in the function chart data which 
identifies the termination transition,, and data which 
identifies the descriptor (and its processor module) that 
is to execute the next section of the function chart 
These descriptor files are stored in the processor mod- 
ule 18 designated in the function chart The function 



The next type of descriptor is represented by the sixth 
descriptor 434 in FIG. 11A, which is produced from the 
simultaneous construct of the FIG. 10 function chart 
The sixth descriptor 434 contains information regarding 
35 its type, the user control program file number and* a 
single transition condition file to be executed. This de- 
scriptor 434 also contains an array of the next descriptor 
files which indicate the descriptors for each of the si- 
multaneous construct branches, in this example branch 



chart interpreter software in each processor module 18 40 steps 415-417. Each of these next descriptors is exc- 
uses the respective descriptor files to control the execu- cuted by its n^^ati-H processor module 18 when the 
tion of each user program. transition condition occurs. 

By way of example with reference to the exemplary The final type of descriptor file is a converge descrip- 

function chart of FIG. 10, a master descriptor file table tor which controls the execution of each simultaneously 

is generated by the progranunmg terminal 24 as shown 45 executing branch, for example, steps 415-417 of the 

in FIG. 11A. The descriptors fall into four distinct function chart in FIG. 10. A converge descriptor is 

catagorics which correspond to the function chart con- generated for each branch. The branch steps 415, 414! 

struct (ie. sequence, selection, simultaneous, and con- and 417 are represented by descriptors 7, 8 and 9 in 

verge) that generated the descriptor. Referring to FIG. 11A. All of the converge descriptor files, as 

FIGS. 10 and 11A the first descriptor 430 represents the 50 shown by descriptions 435 and 436, contain a word 



sequence portion of the function chart and its contents 
are displayed on the right side of FIG. 11A. The first 
word of the descriptor contains several bits, T, which 
indicate the type of the descriptor file, in this case a 
sequence type. The remaining portion of the first word 
identifies the number of the file that contains the user 
control program to be executed for the corresponding 
function chart step. In this example, function chart step 
400 contains the user control program in file 1 for the 



having several bits (T) designating its type and the num- 
ber of the file containing the ladder program for the 
function chart step. Each converge descriptor file also 
contains a pointer to the simultaneous counter address 
55 in the system support file 203 within the memory of the 
system controller module 16, As will become apparent 
in the course of the description of the function chart 
interpreter software relating to the converge portion, 
the simultaneous counter is used to determine when all 



first processor module PI. The first descriptor 430 also 60 of the simultaneous branches have completed their exe- 



contains the number of the transition file which speci- 
fies the condition that is to occur before the execution of 
the user control program should terminate. File 11 is the 
transition file number in the first descriptor 430 as speci- 
fied at point 402 in the function chart Two bits in the 
transition file number field allow the operator to desig- 
nate if the transition is to be forced true or false regard- 
less of the actual state of the condition. This is particu- 



65 



cution. All of the converge branch descriptor files also 
contain the number of the next descriptor file to be 
executed and the processor module containing it The 
converge descriptor file for the rightmost branch, in 
this case the ninth converge descriptor 436, also identi- 
fies the file containing the transition condition upon the 
occurrence of which the simultaneous execution termi- 
nates. 
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Once all of the individual descriptors are assembled 
by the programming terminal 24, they are sorted into 
groups according to the particular processor module PI 
or P2 that has been assigned to interpret them. The 
various user control programs which are specified in 3 
the descriptors are similarly sorted by processor mod- 
ule. The descriptor data and user control program files 
are then transferred by the programming terminal 24 
into the proper processor module 18 in the programma- 
ble controller 10. For example, the function chart de- 10 
scriptors 1-5, 7 and 10 and the user control programs in 
files 1-5, 7, 10-17 and 20 are assembled into a single data 
structure, as shown in FIG- 11B. This data structure is 
downloaded into the program memory area 313 of the 
first program execution processor module PI. The de- 15 
scriptors and user control program files for the remain- 
ing steps and transitions are assembled into another data 
structure as shown in FIG. 11C for the second proces- 
sor module P2. 

Once the sorted files have been downloaded into the 20 
respective processor modules 18, the programmable 
controller 10 is placed in the "run" mode. Each proces- 
sor module 18 contains a function chart interpreter 
program which interprets the descriptors stored in its 
RAM 106 and executes the user control programs 25 
called for by the descriptors. When the execution of a 
machine operation step terminates, such as when the 
transition condition is satisfied, the interpreter program 
may commence interpretation of the next descriptor file 
or notify another processor module 18 that contains the 30 
next descriptor to begin interpreting it As required by 
the descriptors, one or more processor modules can 
execute different portions of the machine operation 
program simultaneously. 

FIGS. 16-1$ illustrate flow charts of the program 35 
which enables each processor module 18 (FIG. 4) to 
interpret and process the various types of descriptors. 
The processing begins at step 590 at the top of FIG. 16 
with the processor module's microprocessor 98 inspect- 
ing a list of active descriptor file numbers stored in its 40 
RAM 106. This active list contains a designation of each 
descriptor file that is currently being interpreted by the 
processor module 18. If there are no descriptors listed, 
the processor module enters a dormant state at step 609 
where it remains until it receives a processing com- 45 
mand. If the list contains an entry, the top descriptor is 
gotten off the active list at step 592 and the remaining 
entries, if any, are moved up in the list. The micro- 
processor 98 then evaluates the bits which indicate the 
type of the descriptor. Based upon the type of descrip- 50 
tor, the program at step 600 branches to one of four 
sections depending upon whether the descriptor is a 
select, simultaneous, sequence or converge type de- 
scriptor. As will be elaborated upon, there are several 
types of converge descriptors which are evaluated at 55 
branch step 607 before branching further to the specific 
routine for that converge type. 

The remaining portion of FIG. 16 is a flow chart for 
the execution of a sequence type descriptor file which 
will be described with reference to the first descriptor 60 
file 430 in FIG. 11A. This branch routine commences 
with the processor module PI at step 601 making one 
execution pass through the user control program speci- 
fied by the step file number within the descriptor. At the 
completion of the pass the file containing the transition 65 
condition indicated in the descriptor file is executed at 
decision block 602. If the condition has not happened, 
the descriptor is returned to the bottom of the active list 
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in the processor RAM 106 at step 606. The program 
then returns to step 590 to get the next descriptor from 
the active list If only one descriptor is on the active list, 
the same user control program will be immediately 
executed again. This loop continues until the transition 
condition has occurred. At this point, step 603, the 
microprocessor 98 interprets the information within the 
first descriptor 430 relating to the next descriptor file to 
determine which program execution processor 18 con- 
tains the next descriptor to be interpreted. If the same 
processor module (PI) is to execute the next descriptor, 
that descriptor file is obtained from RAM 106 at pro- 
gram step 604 and placed in the active list at step 605. 
The program returns to step 590 for the microprocessor 
to check the active list and obtain the next descriptor 
for processing. 

If the next descriptor file is contained in the memory 
of another processor module 18, a command is sent at 
step 608 to that processor module via priority mail as 
described above. The command instructs the other pro- 
cessor module to begin interpreting the next descriptor. 
Once the information regarding the next descriptor has 
been transmitted to and acknowledged by the other 
processor module 18, the previously active processor 
module 18 goes into a dormant state at point 609 unless 
other descriptors remain on the active list. In this dor- 
mant state a processor module 18 may execute back- 
ground and other low priority tasks as will be described. 

In the exemplary function chart of FIG. 10, the selec- 
tion construct is processed next by the first processor 
module PI. As the second descriptor 432 is a selection 
type the program branches to the routine shown in 
FIG. 17. With reference also to the schematic of the 
processor module in FIG. 4, the microprocessor 98 at 
the first step 610 of the routine* determines the number 
of elements in the array of transition condition files. An 
array pointer address in RAM 106 is set at step 611 to 
the first element in the transition condition array. The 
ladder program designated by the step file number in 
the descriptor 432 is then executed by the processor 
module P2 at point 612. 

At the completion of one scan through the user con- 
trol program, the transition condition contained within 
the file specified by the first element of the array is 
evaluated by the microprocessor 98 at step 613 to deter- 
mine if the condition is met If the transition has not 
occurred, the address contained in the array pointer is 
checked at decision block 614 to determine whether it is 
pointing to the address in RAM 106 containing the last 
element of the array. Since it is not the last element, the 
array pointer is incremented at step 615 and the pro- 
gram returns to decision block 613. The transition con- 
dition designated by the next array element is checked 
at decision block 613. Assuming that none of the transi- 
tion conditions specified in the array has occurred, this 
loop continues until the last transition condition in the 
array has been tested. At this point the execution of 
decision block 614 indicates that the array pointer is at 
the address of the last array element and the program 
advances to step 621 where the descriptor is returned to 
the bottom of the active list The processor module 
program execution then returns to step 590 (FIG. 16) to 
process the descriptor at the top of the active list 

The user control program for the select descriptor 
continues to be executed until such time as one of the 
transition conditions in the descriptor array has oc- 
curred. At which point in time, this transition condition 
is found to have been met at step 613 and the program 
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branches to step 616. The microprocessor 98 at step 616 
reads the array field pointed to by the array pointer 
which specifies the file number and location of the next 
descriptor to be processed. At step 617 this next descrip- 
tor specification is evaluated. If the next descriptor is 
stored on the same processor module 18 as the current 
descriptor, the microprocessor 98 will read the descrip- 
tor file from its RAM 106 at process block 618. The 
pr o gram adds the descriptor to the active Hst at step 620 
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When the transition condition 414 has occurred, the 
processing transfers to commence the execution of the 
various function chart branches. The first element in the 
array of next descriptors, descriptor 434, is read from 
RAM 106 by the microprocessor 98 at block 634 and 
the processor module 18 for that next descriptor is then 
determined at block 635. If the module is the same as the 
current one, the next descriptor file is read from RAM 
106 at point 636 and in step 637 is added to the processor 



returns to step 590 in FIG. 16 to process the next de- 10 module's active descriptor list with any other user con- 



scriptor file. 

If the next descriptor is stored in the RAM of another 
processor module 18 for execution, the program will 
branch from decision block 617 to step 619 where the 
current processor module PI sends a command message 
by priority mail to the other processor module 18 speci- 
fying that it is to "wake up" and begin processing the 
next descriptor. This message specifies the file number 
containing the next descriptor. Upon receiving ac- 
knowledgment of the command message, if the active 
list is empty, the current processor module PI enters a 
dormant state at step 609 until it is notified by another 
module 18 that it is to resume processing another de- 
scriptor. 

Referring to the exemplary function chart of FIG. 10, 
each of the selection branches is represented by a sepa- 
rate sequential type descriptor, the third, fourth and 
fifth descriptors in FIG. 11A. The transition from 
whichever one of the selection branches was chosen to 
the next step 413 is a standard sequential type transition. 
Specifically, if step 408 was selected for execution, the 
user control program contained in file 4 will be repeat- 
edly executed until the transition condition 411 con- 
tained in file 16 occurs. At this point the program execu- 
tion transfers to function chart step 413. This transfer 
will be accomplished by the first processor module PI 
sending a priority mail message to the second processor 
module P2 indicating that it is to commence execution 
of the sixth descriptor 434 (FIG. 11A). 

The second processor module P2 contains a copy of 
the function chart interpreter program in its local RAM 
106. Upon receiving the command message from the 
first processor module PI, the second processor P2 adds 



trol programs to be simultaneously executed on this 
processor module. 

If one of the next descriptors is to be executed on 
another processor module (e.g. PI), the descriptor inter- 
15 pretor program branches from decision block 635 to 
step 639 where the current processor module P2 trans- 
mits a command via a priority mail message to that 
other module. The command instructs the other proces- 
sor module to begin interpreting the descriptor file 
20 stored in it. The program then returns through node 640 
to decision block 641 where the microprocessor 98 in 
the first processor module PI determines whether the 
last array element has been processed. If additional 
elements remain, the contents of the array pointer ad- 
25 dress are incremented by the microprocessor 98 at step 
642 and the next descriptor file number is read from the 
array at step 634. 

This process of evaluating each of the next descrip- 
tors continues for each element in the array. Once the 
30 last element has been processed by the currently opera- 
tive processor module P2 at block 641, the program 
returns to step 590 to check the active descriptor list for 
more work. 

In the exemplary function chart depicted in FIG. 10, 
35 the three simultaneous branches, steps 415-417, termi- 
nate in a converge construct. The converge construct 
contains a single transition condition 418 upon the oc- 
currence of which the execution of all the branches 
ceases. Each branch is represented by a separate de- 
40 scriptor (Descriptors 7-9) stored in the RAM 106 of the 
processor module PI or P2 which is designated by the 
user to perform respective step of the function chart. 
Descriptors 7 and 8 are stored in processor PI for exe- 



cution and the ninth descriptor is assigned to the second 
the sixth descriptor 434 to the bottom of its active list. 43 processor P2. One of the descriptors, in this example the 
This action also "wakes up* the second processor mod- ninth one 436 (FIG. 11A) contains the transition condi- 
ule P2 if it was in the dormant state causing the module non and the next descriptor file number, 
to enter its interpreter program at step 590 (FIG. 16). The operation of the second processor module P2 
When the second processor module P2 begins execution will be initially described before discussing the simulta- 
of the sixth descriptor 434, its function chart interpreter » neons operation of the first processor module PI. The 
program will determine at step 600 (FIG. 16) that this ninth descriptor 436 is stored in the second processor 
descriptor is a simultaneous construct type and the pro- module PZ The interpretation of the ninth descriptor 
gram will transfer to the routine indicated by the flow 436 begins on at step 592 FIG. 16 with the processor 
chart of FIG. 18. The first program step 630 in the module's microprocessor .98 reading the descriptor 
interpretation of the simultaneous function chart de- 55 from the active list and evaluating its type. For a con- 
scriptor is the deterniinatkm of the number of elements verge type descriptor the program advances to step 69/7 
in the array of next descriptors which indicates the where a branching occurs depending upon the particu- 
number of simultaneous steps to be performed. The Ur type of converge descriptor as determined by the 
contents of array pointer address in RAM 106 is then set microprocessor 98. In this case the converge descriptor 
to the address of the first element at process block 631. 60 contains the transition condition file number and the 



The user control program contained in file 6, is then 
executed by the second processor module P2 at step 
632. At the completion of one scan of the user control 
program, the occurrence of the transition condition 414 
contained in file 18 is tested at decision block 633. If the 
condition has not occurred, the descriptor is returned to 
the bottom of the active descriptor Hst at step 638, so 
that the user control program will be executed again. 



program advances to node D of the routine shown in 
FIG. 19. This converge descriptor interpreter routine 
begins at block 660 by the nncroprocessor 98 setting a 
pointer to the address of the simultaneous counter con- 
65 tained within the system support file 203 of the system 
controller's main RAM 69 (FIG. 7). The first time 
through the coverage routine for a given descriptor, the 
microprocessor 98 at step 661 loads the simultaneous 
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counter address with the number of simultaneous As noted above, in addition to the function chart and 
branches being executed, in this case three The second user control programs the user also may define "back- 
processor module P2 then begins execution of the user ground tasks** for a specific processor module 18 to 
control program from file 9 at process block 662. At the process. These programs are used to perform lengthy 
completion of one pass through the user control pro- 5 non-time critical tasks without an adverse delay in the 
gram* the microprocessor 98 executes the program in operation of the function chart control program. User 
the transition condition file specified in the ninth de- defined background tasks include report generation and 
scriptor file 436. If this transition condition has not certain subordinate control tasks. Report data regarding 
occurred at step 663, the program replaces the descrip- the performance of controlled equipment may be pre- 
tor on the active list at step 683 and then returns to step 10 pared for transmission via LAN 28 to a host computer. 
590 (FIG. 16). Such reports are not so urgent that the control of the 
However, if the transition condition has occurred, the equipment must be suspended while they are prepared 
second processor module P2 at step 664 sets a flag in the sent * Tte background control tasks also are used for 
system controller RAM 69 indicating the end of the lengthy calculations which are similar to those found in 
simultaneous execution. While the second module P2 13 inain function chart program, but which are not 
has access to the system controller RAM 69, it decre- required for real time control. 

ments the simultaneous counter at step 669 indicating A background task program may be invoked from a 
that the processing of its simultaneous branch has been control program, an interrupt routine such as a 
completed. Next at step 666, an evaluation of the selectable timed interrupt, or from another background 
counter is made by the second processor module P2 to 20 P ro & ranL A percentage of the processing time for each 
determine if the counter has reached zero. If the count processor module 18 has been allocated to performing 
is not zero the p r ogr am returns to step 590 (FIG. 16) to tnese back * rouiKl tasks. This percentage is set by the 
see if other descriptors remain to process. As none are uscr . 50 th&t execution of background tasks do not 
left for the second processor module P2, it enters a significantly affect the execution of the machine opera- 
dormant state in step 609. 23 don program. Periodically the processing of the user 
If all of the simultaneous execution is completed fi e, co ^ tr ? 1 program is interrupted by the real time clock 
the count at step 666 is zero), the second processor . ^8""""* ***** performed for a given 
module P2 at step 667 examines which processor mod- mtcrval oftime - Uihe of background task exe- 
ule is to execute the next descriptor. If the second pro- « cution period occurs before the completion of the back- 
cesser module P2 is to begin executing the nextdescrip- 30 program, the execution of the background task 
tor file, its microprocessor 98 at process block 668 reads *; f 25 **?^* 1 ^ resumed during the next back- 
the next descriptor and adds it to the active list at step mterv £. **** a control program is 
670. Then the rm>gram returns to step 590 at the be^ not being run on the processor module 18 the back- 
ning of the routine in FIG. 16 where it processes^- „ ^^1^ T y 1 n)n almost contmuoudy. In normal 
new^ descriptor. If the next descriptor is £1^d£ 33 ^\t^ T 
by another processor module (e^ PI), the routine ^^£?toon, however their execution may be 

branches to step 669. The second ^modul e P2 scndTa ^^fl^Tl^^™*™* °' ^ OCCUr " 
priority mail message to that other module Pi informing rence of an error condition. 

it to begin executing the next descriptor ThX^ „ JSl^ S^ SyStCm 
end processor module P2 enters the dormant state at 40 ^SilT^ 18, no single processor 
stcv u ig, constantly devoted to running the user control pro- 

a*. ^ * • „„i ^ „ . . . , _ grams. This results in time being available for the pro- 
v^J^^J ^^^JT^ t ^^ C ° n ' modulcs *> P«*«- Aground tasks, whhow 
^^t^^^^^^S^^^L^' such *«»ks adversely affecting the control of the manu- 
^L^T^^T T ^ W ) d ° « factoring equipment. This is yet another benefit of the 
not contom any formation regarding the transition present parallel processing concept as applied to pro- 
condition (see the eighth description 435 of FIG. 11A). grammable controllers. PP cu ui pro- 

^J^SS ^,^ tCrPrC ? d °" *• ^ P rcsrat Programmable controller 10 also pro- 

proce»c«r module PI. When ^ descnp^ are evala- vide, a two mode power loss recovery mechanism. This 

^^™T"Z^"° r If^L* 7 ° fFIG - 16 > » recovery mechanSm is activated whenever power is 
TiESfSTZJl ro « nun J n *■« «*P«*™ processor loat during the execution of the machine operation pro- 
T££ V^TSSf £ S °1 rOUtln = illustrated gram, such as due to an electric power outage. The 

^ address r^ter is set at operator may select during system configuration 

JSSL^Ei^ ^"L 0 ^" 8ddresS f *• whether . wta Power is restored after such a loss, 
system controller main RAM 69. The user control pro- 55 the program restarts at the beginning (Le. the initial 
gram is then executed by the microprocessor 98 at step function chart step) or resumes execution at the start of 
681. After each user control program scan, the end flag the user control program that was being executed when 
address in the system compiler mam RAM 69 is the power failed. The operator's selection of the recov- 
checked at step 682 to determine whether or not it has cry mode is stored in the system status file 201 in the 
oeen set, thereby indicating that the control program 60 system controller's m»4n RAM 69. 
processing is to terminate. If the flag is not set, the With reference to FIG. 3, the system status circuit 88 
descriptor is returned to that processor's active list at detects the power beginning to fail and interrupts the 
step 689. If the flag is set, the simultaneous counter is processor section's microprocessor 66. This causes the 
decremented twice at step 665 to indicate that the exe- microprocessor 66 to execute on interrupt subroutine 
cution of rues 7 and 8 by this processor module PI is 65 which stores the state of each processor module's de- 
ceasing. The first module PI then at step 666 checks the cution in a non-volatile memory. This state data in- 
simultaneous counter and proceeds as previously de- eludes the file numbers of the descriptors currently 
senbed with regard to steps 666-670. being executed and the descriptors on each processor 
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module's active descriptor list Information regarding 
any background tasks being executed is also saved. 

When power is restored, if the resume mode is se- 
lected, the system controller notifies each processor 
module 18 to begin execution with the descriptor file 5 
number that was stored when the power failed. As 
noted above, the major modules in the system have 
internal batteries to keep their respective memories 
alive when the power is shut off. Therefore, the pro- 
grams and I/O tables remain stored in the modules' 10 
memories during the power outage. 

What is claimed is: 

1. A programmable controller for operating a ma- 
chine to carry out a plurality of programmed functions, 
which comprises: 15 

a backplane bus having leads for conducting data 
signals, address signals and control signals; 

a plurality of processing means connected to said 
backplane bus, each processing means being opera* 
ble to simultaneously execute a separate user con* 20 
trol program that directs the programmable con- 
troller to operate the to perform a specific 
function; 

a memory means which stores program execution 
sequence data and a plurality of user control pro- 25 
grams, said memory means coupled to said plural- 
ity of processing means; 

means responsive to the program execution sequence 
data for controlling the execution of the user con- 
trol programs by said plurality of processing 30 
means; 

an I/O interface means connected to said backplane 
bus for coupling the programmable controller to 
I/O devices, and 
a system controller for supervising the access of said 35 
plurality of processing means and said I/O inter- 
race means to said backplane bus. 
X The programmable controller as recited in claim 1 
wherein at least one of said processing means comprises 
means for interrupting the program execution by that 40 
processing means in response to an interrupt signal from 
an apparatus that is external to said programmable con- 
troller. 

3. The programmable controller as recited in claim 2 
wherein at least one of said processing means further 45 
comprises means for executing an interrupt program 
routine after the program execution is interrupted by 
said means for interrupting. 

4. The programmable controller as recited in claim 1 
wherein said program execution sequence data com- 50 
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prises a series of descriptors, each descriptor containing 
an identification of a user control program, an identifi- 
cation of a transition condition which indicates when 
the execution of the identified user control program is 
to terminate, and an identification of the next descriptor 
to be processed and which processing means will pro- 
cess the next descriptor. 

5. The programmable controller as recited in claim 4 
wherein each of said processing means includes means 
for interpreting the descriptors. 

6. The programmable controller as recited in claim 4 
wherein each of said processing means includes means 
for forcing the transition conditions to be either true or 
false regardless of the actual state of the condition. 

7. The programmable controller for operating a ma- 
chine to carry out a plurality of programmed functions, 
which comprises: 

a backplane bus having leads for conducting data 

signals, address signals and control signals; 
a plurality of processor means connected to said 
backplane bus, each processor means having a 
memory for storing user control programs for exe- 
cution on that processor means and program exe- 
cution sequence data comprising a plurality of de- 
scriptors each identifying a user control program, a 
transition condition which indicates when the exe- 
cution of the user control program should termi- 
nate, and the next user control program to be exe- 
cuted and which processor means is to execute the 
next user control program, each of said processor 
means having means to transmit program execution 
co mm ands to other processor means; 
an I/O interface means coupled to said backplane bus 
for coupling I/O devices to the programmable 
controller, and 
means for controlling access to said backplane bus by 
said plurality of processor means and said I/O 
interface means. 
& The programmable controller as recited in claim 7 
wherein said program sequence data further comprises 
a designation of one of the user control programs to be 
executed initially at the start of program execution. 

9. The programmable controller as recited in claim 7 
further comprising means for saving program execution 
status data for each pr oce ss or means upon an electrical 
power failure so that programs which were executing 
when the power failure occ ur red can resume executing 
upon restoration of electrical power. 
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METHOD AND SYSTEM FOR 
INTELLIGENTLY CONTROLLING A 
REMOTELY LOCATED COMPUTER 

CROSS-REFERENCE TO RELATED CO- 
PENDING APPLICATION 

The present invention is a CIP of application Sen No. 
08/916,685, filed Aug. 22, 1997, now abandoned. The 
contents of that application are incorporated herein by 
reference. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is directed to a method and system 
for intelligently controlling a remotely located computer. 
More specifically, the present invention is directed to a 
control system connected to a video output port and at least 
one data input port of a computer located in a first location. 
A user located in a second location, remote from the first 
location, controls the computer in the first location through 
the control system as if the user were directly connected to 
computer at the first location. 

2. Discussion of the Background 

Modem computing has migrated away from the use of 
centralized mainframes to the use of individual (or personal) 
computers. With that migration has come a decentralization 
of many of the resources that were centralized in a main- 
frame environment (e.g., peripheral devices including mag- 
netic or optical disks and their associated files). That decen- 
tralization has not been accompanied by an equivalent 
increase in peer-to-peer networking capabilities such that 
those decentralized resources are available to a user as the 
user moves. Moreover, system administration of multiple 
physically remote systems increases maintenance concerns. 

As a result of the lack of peer-to-peer access, a number of 
systems have been developed to provide control of remote 
computers. Unfortunately, many of those solutions have 
provided very limited control of the remote computer. The 
most rudimentary type of control is a text-based dialup 
connection. Control of the remote system is then performed 
through terminal emulation. Control using terminal emula- 
tion is also possible through network connections as 
opposed to dialup connections. Using (1) a telnet server (or 
daemon) on the remote computer and (2) a telnet client on 
the local computer, a user can connect to a remote 
computer — even across a wide area network (e.g., the 
Internet). However, telnet access also is limited by the fact 
that such control requires additional software (i.e., the 
server) to be running on the remote computer. Such server 
software may "crash" due to the errant operation of the 
computer. As a result, access to and control of the remote 
computer is lost after a crash or after a system "hang." In 
addition, such server software does not begin running on the 
remote computer until after the boot-up sequence. Thus, it is 
not possible to watch or alter the boot-up process using a 
telnet server. 

More sophisticated remote control systems include the 
capability for graphics. Carbon Copy 32 from Compaq and 
LapLink from Traveling Software allow for remote access of 
computers while enabling a graphical user interface of the 
remote computer to be displayed at a user's local computer. 
Carbon Copy and LapLink on Windows 95, 98, NT and 
2000 utilize "hooks" in the display subsystem of the remote 
computer to capture drawing requests (in the form of GDI 
calls). Those drawing requests are sent via a communica- 
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tions adapter to a Carbon Copy or LapLink client program 
running on the local computer. Once the drawing requests 
are received locally, the Carbon Copy or LapLink client 
program "re-executes" the requests so that the drawing 
5 operation is performed locally. Accordingly, the local com- 
puter displays both the local and remote images. 

In addition, when using Carbon Copy or LapLink in a low 
to medium bandwidth connection (e.g., a 28.8 K or 56 K 
modem connection over a telephone line), the amount of 
1° data to be transferred becomes an important issue. In such a 
connection, there is insufficient bandwidth to send a com- 
plete copy of the screen frequently. PCAnywhere produced 
by Symantec of Cupertino, Calif, is an additional remote 
control program requiring server software on the remote 
15 computer in order to transfer graphics between computers. 
An alternate graphical control system is the X Windows 
system, often run on UNIX workstations. Using X 
Windows, a server program running on a local computer 
receives drawing requests from an application running on 
20 (i.e., using the CPU and memory resources of) a remote 
computer Although it is possible to utilize the X Windows 
graphical user interface over a wide area network, the X 
Windows system, like the terminal emulator and Carbon 
Copy systems, requires that application software be running 
25 on the remote computer in order to control the remote 
computer. That requirement prevents an X Windows-based 
system from being able to analyze or modify the boot 
process of the computers that it controls. 

U.S. Pat. No. 5,732,212, to Perholtz et al., entitled "SYS- 
TEM AND METHOD FOR REMOTE MONITORING 
AND OPERATION OF PERSONAL COMPUTERS," dis- 
closes a system in which the video, keyboard and mouse 
ports of a remote computer are connected to a host unit. The 
35 host unit may communicate with a local computer via a 
modem connection over phone lines. As described in the 
abstract of that patent, the video raster signal is converted to 
digital form. 

SUMMARY OF THE INVENTION 

1-0 

It is an object of the present invention to provide control 
of a remote computer independent of the operating system of 
the remote computer. 

It is a further object of the present invention to provide a 
i5 method and system for analyzing the screen information 
transmitted between the remote control system and the local 
computer in order to reduce the required bandwidth. 

These and other objects of the present invention are 
provided by a remote control system that connects to a 

50 remotely located computer via a video port and one or more 
data input/output ports (e.g., keyboard, mouse, touch- 
screen). The system does not utilize resources of the 
remotely controlled computer, thus, the present invention 
operates independently of the operating system (and BIOS) 

55 of the remotely controlled computer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete appreciation of the invention and many 
of the attendant advantages thereof will become readily 
60 apparent with reference to the following detailed 
description, particularly when considered in conjunction 
with the accompanying drawings, in which: 

FIGS. 1A-1C are block diagrams of a system for access- 
ing and controlling a remotely located target computer 
65 system according to the present invention; 

FIG. 2 is a schematic illustration of the controlling 
computer of FIG. 1A; 
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FIGS. 3a through 3c are block diagrams of the relation- 
ship between the software and the hardware of several 
embodiments of the present invention; 

FIG. 4 is a schematic illustration of a series of uncom- 
pressed video signals representing the image generated by 5 
the video card of the remote computer; 

FIGS. 5A and 5B are graphical illustrations of the same 
block of the video memory of FIG. 4 between successive 
image captures by the system of the present invention; 

FIG. 6 is a schematic illustration of one embodiment of an 
intelligent video digitizer as shown in FIG. 3c; 

FIGS, la and lb are block diagrams showing status 
registers indicating the status of blocks of the screen; 

FIG. 8 is block diagram showing status flags indicating is 
which bits in a block have changed; 

FIGS. 9a and 9b are block diagrams showing compres- 
sion headers and data for sending incremental changes; and 

FIG. 10 is a block diagram of a circuit for altering the 
phase of when pixels are sampled. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

Referring now to the drawings, in which like reference 2 5 
numerals designate identical or corresponding parts 
throughout the several views, FIG. lAis a block diagram of 
a system for accessing and controlling a remotely located 
computer system according to the present invention. In 
general, the system of the present invention transmits a GDI 30 
representation of digitized video signals as well as mouse 
and keyboard signals over a communications link. Since 
"local" versus "remote" is a matter of perspective, a set of 
consistent terminology is used throughout this application 
which ignores relative perspective. Herein, the phrase "tar- 35 
get device" refers to a computer or switch that has its video 
output connected to the digitizer of the present invention. 
For example, in FIG. 1A, the computers 20a through 20c are 
connected through switch 74a. Thus, any of those computers 
20, as well as the switch 74a, may be referred to herein as 4 o 
a target device. When referring to a target device that is a 
computer, that computer herein is referred to as a target 
computer. Similarly, when referring to a target device that is 
a switch, that switch is referred to herein as a target switch. 
Typically, the target computers are server computers that are 45 
connected to a computer network and operate to perform 
such tasks as controlling the operation of the network, 
storing commonly used programs or data, or connecting a 
local area network (LAN) to a wide area network (WAN) 
(e.g., the Internet). Those computers may be either comput- 50 
ers in separate housings or part of a rack-mounted system. 
In an alternate embodiment, a target computer is a computer 
that controls any external hardware or equipment (including 
storage area network, factory equipment or consumer 
electronics/appliances). 55 

By contrast, the computer that indirectly controls the 
target device(s) is referred to herein as "the controlling 
computer." The computer 12 in FIG. 1A is the controlling 
computer and is shown in greater detail in FIG. 2. 
Specifically, the computer 12 includes a computer housing 60 
102 that houses a motherboard 104. The motherboard 104 
includes a CPU 106 (e.g., Intel 80x86, Motorola 68x0, or 
PowerPC), memory 108 (e.g., DRAM, ROM, EPROM, 
EEPROM, SRAM, SDRAM, and Flash RAM), and other 
optional special purpose logic devices (e.g., ASICs) or 65 
configurable logic devices (e.g., GAL and reprogrammable 
FPGA). The controlling computer 12 also includes plural 



input devices, (e.g., a keyboard 122 and mouse 124), and a 
display card 110 for controlling monitor 120. In addition, the 
computer system 12 further includes magnetic or optical 
storage devices. Such storage devices include, but are not 
limited to, a floppy disk drive 114; compact disc reader 118, 
tape; and a hard disk 112, any of which are connected using 
an appropriate device bus (e.g., a SCSI bus, an Enhanced 
IDE bus, or an Ultra DMA bus). Also connected to the same 
device bus or another device bus, the computer 12 may 
additionally include a compact disc reader/writer unit (not 
shown) or a compact disc jukebox (not shown). Although a 
compact disc 119 is shown in a CD caddy, the compact disc 
119 can be inserted directly into CD-ROM drives that do not 
require caddies. In addition, a printer (not shown) also 
provides printed listings of operations of the present inven- 
tion. 

As stated above, the system includes at least one computer 
readable medium. Examples of computer readable media are 
compact discs 119, hard disks 112, floppy disks, tape, 
magneto-optical disks, PROMs (EPROM, EEPROM, Flash 
EPROM), DRAM, SRAM, SDRAM, etc. Stored on any one 
or on a combination of computer readable media, the present 
invention includes software for controlling both the hard- 
ware of the computer 12 and for enabling the computer 12 
to interact with a human user. Such software may include, 
but is not limited to, device drivers, operating systems and 
user applications, such as development tools. Such computer 
readable media :frther includes the computer program prod- 
uct of the present invention for remotely accessing and 
controlling a target computer (or switch). The phrase "com- 
puter code devices" as used herein can be either interpreted 
or executable code mechanisms, including but not limited to 
scripts, interpreters, dynamic link libraries, subroutines, 
Java methods and/or classes, and partial or complete execut- 
able programs. Moreover, although portions of the specifi- 
cation describe the operation of portions of the present 
invention in terms of a microprocessor and a specially 
programmed memory, one of ordinary skill in the art will 
appreciate that a portion of or all of those described func- 
tions may be implemented in a configurable logic device. 
Such a logic device may be either a one-time programmable 
(OTP) logic device or a field programmable gate array 
(FGPA). It will also be appreciated by one of ordinary skill 
in the art that a single computer code device and/or logic 
device may implement more than one of the described 
functions without departing from the spirit of the present 
invention. 

In addition, in a first embodiment using a "system on a 
chip," the present invention is implemented as (1) a digital 
system that includes an integrated microprocessor, memory 
and specialized logic on a single- or multi-chip module and 
(2) analog-to-digital and digital-to analog converters. In a 
second embodiment using a "system on a chip," the present 
invention is implemented as a mixed-signal system that 
includes an integrated microprocessor, memory, specialized 
logic, and analog-to-digital and digital-to analog converters 
on a single or multi-chip module. As used herein, "means" 
will be understood to include any one of the computer code 
devices, logic devices, and/or systems on a chip, in any 
combination. That is, although one "means" may be a 
computer code device, it may interact with another "means" 
that is a logic device. 

The controlling computer 12 also includes a communica- 
tions device 53 for communicating with the target device(s). 
Such a device 53 may include (1) a modem for connecting 
via a telephone connection, (2) a wireless transceiver for 
wirelessly communicating, and (3) a wired adapter (e.g., an 
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Ethernet or token ring adapter). In any of those 
configurations, the controlling computer 12 communicates 
with a target controller 50 using any selected communica- 
tions protocol (e.g., TCP/IP, UDP, or RDP). In an alternate 
embodiment, the controlling computer 12 is a set-top box 5 
that receives the output of a target device via a television 
connection (cable or satellite) and enables the output to be 
displayed on a television or similar device (e.g., WebTV). 
Controlling computer 12 can likewise be a notebook, hand- 
held or palm- top computer. 10 

In addition, more than one communications device 53 can 
be used simultaneously. For example, two or more commu- 
nication devices may be combined in parallel in order to 
increase bandwidth. Moreover, separate adapters may be 
used for transmitting and receiving. Moreover, although the 15 
controlling computer 12 is illustrated as using a single 
communications channel, in an alternate embodiment, plural 
communications channels are used to communicate with 
plural independent target computers. 

Commands or keystrokes entered at the keyboard 122 or 20 
mouse 124 of the controlling computer 12 operate to control 
the target computer 20 as if the command had been entered 
using a keyboard or mouse that is directly connected to the 
target computer 20. In addition, the monitor 120 of the 
controlling computer 12 displays the same video signals that 25 
are captured from the video adapter of the target computer 
20. 

Generally, a target controller 50 is a computer including 
at least one controller card. Each controller card is connected 
to one or more target devices (i.e., computer 20 or switch 
74). Each controller card physically connects to at least one 
set of interfaces including: (1) a video interface 82, (2) a 
keyboard interface 84 and (3) a mouse interface 86. In an 
alternate embodiment, the keyboard and mouse are merged 
into a single interface (e.g., USB or Macintosh-style). (In an 
alternate embodiment, one or more interfaces may be 
wireless, and "connected peripheral devices" as used herein 
shall refer to wired and wireless peripheral devices.) 

In addition, the total number of target devices that are 
logically connected simultaneously may be even greater if 
the target device is a switch 74a (connected to several target 
computers 20) rather than a single target computer 20. 
Moreover, although each of the target computers 20a 
through 20c is illustrated as having separate housings, the 
present invention is not limited thereto. More than one target 
computer may be contained within a single case. 

In the embodiment shown in FIG. 1A, the target controller 
50 is implemented as a computer having similar components 
to the controlling computer 12. Those components include 
computer code devices for performing portions of the 
method of the present invention. In the embodiment of FIG. 
1A, the target controller 50 includes at least one internal 
"plug-in" or "add-in" card labeled "Controller card 1." In an 
alternate embodiment, the target controller 50 includes at 
least one controller integrated onto the motherboard of the 
computer. In either of those embodiments, the target con- 
troller 50 optionally also attaches to local keyboard, mouse 
and video connections. 

In yet another alternate embodiment, the target controller 
is a stand-alone device similar to a router or a switch. In the 
router/switch configuration, the keyboard, mouse and screen 
are not required and the router/switch is configured 
remotely — either through the communications device 53 or 
through a separate control interface (not shown). Remote 
configuration may be via a direct connection, a local area 
network or a wide area network (e.g., the Internet). In 
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addition, the router/switch configuration may be updated 
through a removable medium (e.g., a floppy disk or 
CD-ROM) inserted into the router/switch. In the preferred 
embodiment, the target controller 50 is a computer system 
running Windows NT (or its successor Windows 2000) and 
is connected to at least one plug-in card. Alternate embodi- 
ments utilize Windows CE, UNIX, Linux or MacOS as the 
operating system. 

The target controller 50 can be further reduced and 
integrated into a KVM switch or into another target device 
(e.g., integrated on the motherboard of a target computer or 
included on a peripheral card of the target computer). 
Illustrative embodiments are shown in FIGS. IB and 1C. 

After configuration, the target controller 50 operates to 
capture the video output of the target device. The captured 
video signals are stored in either a frame buffer internal to 
the controller card or in a memory shared with other 
components of the computer. In addition, the controller card 
50 fills a set of keyboard/mouse buffers internal to the 
controller card with keyboard and mouse commands to be 
sent to the target device. If the target device supports 
bidirectional mouse and keyboard communication, then the 
controller card also includes at least one buffer for receiving 
communications from those devices. Those commands are 
sent to the controlling computer 12. 

The controller 50 includes a video digitizer that receives 
and converts the analog signals output by connected target 
device. The controller stores the converted signals in digital 
form in the video memory (shared with the mother board or 
dedicated to the controller card) as digital video data. After 
a configurable amount of processing, the digital video data 
is sent from the target controller 50 to the controlling 
computer 12. Based on the desired cost, complexity and 
performance of the controller, various processing tasks are 
divided between the hardware and software of the controller 
50. 

The initial starting point, however, is the pixel depth of 
the pixels to be rendered on the controlling computer 12. In 
order to determine that depth, a user must consider both the 
depth of the target device and the amount of available 
bandwidth between the controller 50 and the controlling 
computer 12. If the pixel depth being transferred is low but 
the pixel depth of the target device is high, then the ability 
to represent color gradations may be severely impaired. In 
fact, similar colors that are readily distinguishable on the 
target device may become indistinguishable on the display 
of the controlling computer. On the other hand, higher pixel 
depths require larger amounts of bandwidth to transfer and 
some loss of color separation may be acceptable. 

In one embodiment of the present invention, the controller 
samples at eight bits per color, providing a 24-bit color 
sample. In another embodiment, the present invention 
samples at 5 bits per color to reduce the cost of the A/D 
converter. The samples are then converted into a bitmap in 
one of several formats: (1) 8-bits-per-pixel, (2) 16-bits-per- 
pixel, (3) 24-bits-per pixel, and (4) device independent. 

FIG. 3a illustrates that, in a first embodiment, the hard- 
ware (digitizer 70) and software 230 (including device 
driver 210 and the digitizer control application 220) of the 
controller 50 simply act as a thin interface to a remote 
control software application 200. When providing the thin 
interface, neither the software 230 nor the digitizer 70 
performs any analysis on the video signals captured by the 
digitizer 70. Instead, the digitizer control application 220 
periodically requests (through the device driver 210) that a 
whole screen of data be sampled. The digitizer control 
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application 220 then draws the whole captured screen to its 
local screen using Windows GDI calls. The remote control 
software application 200 captures those GDI requests and 
retransmits them to the controlling computer 12. The client 
software on the controlling computer 12 then re-executes the 5 
commands so that the screen of the controller 50 and the 
screen of the controlling computer 12 show the same image. 

An illustration of an exemplary method of storing the 
captured/digitized data is shown in FIG. 4. In that 
illustration, the red, green and blue components of each 10 
pixel are captured and stored together. In an alternate 
embodiment, the red, green and blue values are stored 
separately such that the red value for pixel number 1 is 
adjacent in memory to the red value for pixel number 2. 

Several embodiments are possible for the storage and 15 
transmission of the digitized data. It is possible that the data 
is quantized at one depth (bits-per-pixel), stored at a second 
depth (greater or less than the quantized depth), and trans- 
mitted in a third depth. However, in an alternate 
embodiment, one or more of those depths may also be the 20 
same. In the case of quantizing at 5 bits per color (i.e., 15 bits 
per pixel), the 15 bits per pixel are converted into a device 
independent bitmap using 24 bits per pixel. Prior to trans- 
mission by LapLink or Carbon Copy, the 24 bits per pixel 
are converted to a "closest" color in the corresponding color 25 
palette (which may be 8 bits per pixel). 

Although compression is not required, in this thin- 
interface embodiment, the preferred remote control software 
application 200 is LapLink by Traveling Software since, 3Q 
before transmission to the controlling computer 12, LapLink 
performs some analysis and lossless compression on the 
image resulting from the captured GDI calls. Accordingly, in 
that thin -interface embodiment, LapLink can be replaced by 
any other remote control application but preferably one that 
also performs lossless compression on the captured GDI 
calls before transmission. 

In the second embodiment illustrated in FIG. 3b, the 
digitizer 70, the device driver 210, and the remote control 
software 200 remain consistent with their corresponding 40 
parts described in relation to FIG. 3a. However, the digitizer 
control application 220 of FIG. 3a is replaced by an ana- 
lyzing digitizer control application 240. Trie analyzing digi- 
tizer control application 240 requests, through the device 
driver 210, that a screen be captured (i.e., digitized). Rather 45 
than using GDI calls to redraw the entire screen (which 
would be captured in its entirety by the remote control 
software 200), the analyzing digitizer control application 
240 analyzes the captured image and uses GDI calls to 
redraw only changed blocks instead. Those changed blocks 50 
are captured by the remote control software 200. 

For example, in the preferred embodiment of this 
implementation, the analyzing digitizer control application 
240 partitions a screen into blocks (e.g., 32 pixels by 32 
pixels), an example of which is shown in FIG. 5a. Although 55 
one embodiment uses fixed size blocks, an alternate embodi- 
ment uses blocks of varying size and shape. For example, 
where large blocks of the screen are a single color, the block 
size may be increased (e.g., to 64x64 or 128x32) in order to 
optimize solid block transmission, as is described in greater 50 
detail below. Although any size block can be used, other 
preferable blocks size are: 16x16, 16x32, 32x16, and 64x16. 

For each block, the analyzing digitizer control application 
240 determines if there is a more efficient way to draw a 
block. One method of drawing a block utilizes identification 65 
of solid blocks — i.e., blocks of a single color. In many 
backgrounds, there exist regions that are a single color (e.g., 



all blue or all white). Once identified, those blocks can be 
more efficiently drawn by using a single GDI call indicating 
that a colored region is to be drawn at a particular (x, y) 
location on the screen. This method, however, requires that 
the CPU of the computer system perform the analysis of 
which blocks are a single color. In a high resolution, 
1280x1024 screen using 32x32 blocks, for each screen 
update, the CPU checks 1280 blocks that are 32x32 pixels 
each. 

The present invention may also identify "solid" blocks 
which are blocks that probably should have been a single 
color, but, through errors in digitization, are not exactly one 
color. The present invention can be configured to establish 

(1) a percentage threshold, (2) an intensity threshold or (3) 
both. The percentage threshold represents the number of 
errant pixels within a block that can deviate from the "solid" 
color, regardless of how far from the "solid" color they are, 
and still treat the block as a solid block. The intensify 
threshold represents the amount that any pixel can vary from 
the "solid" color before the block is considered not to be 
solid. By combining the percentage threshold and the inten- 
sity threshold, the system can limit both the number of errant 
pixels and amount of variation, simultaneously. 

Improved performance is not, however, limited to iden- 
tifying solid-colored blocks. The analyzing digitizer control 
application 240 can also improve efficiency by tracking 
which blocks change between successive screen captures. To 
track those changes, the analyzing digitizer control applica- 
tion 240 double buffers the digital video information 
received from the device driver. In this way, the analyzing 
digitizer control application 240 can compare (1) the screen 
information stored in a first buffer for a previous frame and 

(2) the screen information stored in a second buffer for the 
image currently being captured. The buffer sizes need not 
actually be the same sizes as long as the corresponding 
blocks can be compared in a non-destructive fashion such 
that the currently captured block can replace the correspond- 
ing block from the previous screen after comparison. Having 
identified the changed blocks, the analyzing digitizer control 
application 240 then need only redraw the changed areas as 
they change. The remote control software 200 then captures 
and transmits those changed blocks. 

Unfortunately, as described above, the digitization/ 
quantization process may introduce errors in producing 
digital data. Those errors not only affect the ability to 
identify solid blocks, those errors also cause blocks to 
appear as if they changed when the blocks have actually 
remained constant. For example, the memory block shown 
in FIG. 5 A represents the data sampled during a first time 
period. The memory block shown in FIG. 5B represents the 
same block sampled during a subsequent time period. As can 
be seen, the value in location 500 has changed from 255 to 
254. Without further analysis, it would appear that this block 
has changed. In the illustrated example, the change requires 
that the block be retransmitted. In all likelihood, the value 
would change back a short time later and the block would be 
retransmitted yet again. 

To prevent such digitization errors from increasing the 
amount of data transferred between the target controller 50 
and the controlling computer 12, in one embodiment of the 
analyzing digitizer control application 240, the analyzing 
digitizer control application 240 filters the sampled data to 
hide small changes. In a first filtering embodiment, the 
analyzing digitizer control application 240 stores both the 
filtered data from a previous image and an unfiltered copy of 
the previous image. The current image is then captured, 
stored and a filtered version of the current image is stored 
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separately from the unfiltered version. (It will be appreciated 
by one of ordinary skill in the art that the entire current 
image and its filtered equivalent need not be stored. Rather, 
once the processing of a block (or group of blocks) is 
complete, the previous block is replaced by the current 
block, and the area for the "current" block is reused for the 
next block.) 

In one embodiment, a finite impulse response (FIR) filter 
averages the current pixel's value and the pixel value from 
the previous frame. That average is then averaged with the 
previous average from the previous frame. (Rounding (up or 
down) may be used in light of the division that is inherent 
in the averaging process.) The two filtered images are 
compared for changes. If there are changes, then the block 
is drawn, in either its filtered form or its unfiltered form. 

In another filtering embodiment, the analyzing digitizer 
control application 240 stores a copy of the unfiltered block 
for a previously sampled screen and calculates differences 
between the unfiltered block and a currently sampled block. 
The differences are stored in a difference block, and the 
difference block is filtered and compared against a threshold 
(or compared against a threshold and then filtered) to 
determine if the new block (or portions thereof) should be 
redrawn. (It will be appreciated by one of ordinary skill in 
the art that the filtering step may be omitted if the use of a 
threshold is found to be sufficient to avoid quantization 
errors.) 

In any of the above filtering embodiments, the analyzing 
digitizer control application 240 may actually inadvertently 
prevent small changes from being transmitted to the con- 
trolling computer 12 — even when the changes are the result 
of an application's actions. To prevent the filtering and 
thresholding from impeding a user's ability to see those 
small changes, blocks that have changed (but that nonethe- 
less have changed less than the threshold amount before or 
after filtering), may be sent (in whole or in part) when 
bandwidth is available. An area of interest may also be 
designated by the user such that these system ignores 
changes to sampled data in the area outside of the area of 
interest. 

In one embodiment of the present invention, the filtering 
of blocks is changed dynamically. For example, the thresh- 
old levels may be increased when the user wants to decrease 
network traffic. In addition, in an alternate embodiment, the 
system includes a percentage threshold that causes a block 
not to be treated as changed as long as a total number of 
pixels within the block that have changed is less than the 
threshold — regardless of how much those pixels have 
changed. As a result fewer blocks are treated as "changed" 
and fewer drawing requests are made. Likewise, the system 
may change from one block size to another or from one filter 
to another. 

The filtering and thresholding process described above 
with reference to the analyzing digitizer control application 
240, may likewise performed (wholly or partially) in hard- 
ware as part of an intelligent digitizer 75 shown in FIG. 3c. 
The intelligent digitizer 75 is shown in greater detail in FIG. 
6. The video A-to-D/PLL 705 is a triple high speed Analog- 
to-Digital Converter that contains an integrated PLL, and a 
serial digital interface for setting individual registers (e.g., 
registers controlling control the pixel clock and clamping 
settings). The input signal used by the PLL is the polarized 
HSYNC (PHSync) signal. This is then multiplied by the 
value set in one of the internal registers to produce the 
desired pixel clock frequency. The output is then provided to 
the Video DSP and PCI FPGAs in order to capture video at 
the required pixel clock rate. 
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In one embodiment of the present invention shown in 
FIG. 10, the system adjusts when the pixel is sampled by 
adjusting the phase of the A-to-D convertor 705 — i.e., the 
delay between the active edge of the PHSYNC signal as 
compared to the first active edge of the sample clock after 
the active edge of the PHSYNC signal. As shown in FIG. 10, 
in the preferred embodiment, the blue signal from the RGB 
inputs is used as the positive input to the comparator 1000a. 
In alternate embodiments, the red or green signal may be 
used. In yet another embodiment, two or more of the color 
signals are combined to form the positive input. As shown 
in FIG. 10, the blue signal is filtered by applying a low 
threshold signal to the negative input of the comparator 
1000a. The filtered blue signal then acts as the clock input 
of a D flip-flop 1005. The output of the A-to-D converter 705 
is the sample clock shown in FIG. 6), which is also applied 
to the D input of the D flip-flop 1005. The output of the D 
flip-flop ig fed out to the PCI FPGA where its status can be 
read by the analyzing control application 220 as if the output 
were part of a register of the FPGA. In the preferred 
embodiment, the D flip-flop is included in the CPU Interface 
CPLD, 

In order to control the phase, the analyzing control 
application 220 reads the status of the output of the D 
flip-flop 1005 (e.g., once per frame). When the output is a 1, 
the delay of the A-to-D convertor 705 is moved one unit in 
a first direction by sending a command to the microproces- 
sor 700 (which then adjusts the delay using the I2C bus). 
Conversely, when the output is a 0, the delay is moved one 
unit in a second direction opposite the first direction. In the 
A-to-D convertor 705 of the preferred embodiment, each 
unit corresponds to approximately 11 degrees. In light of this 
circuit and the fact that the delay is reprogrammed, the 
system will oscillate between reading a status of 1 and 0. 
This causes the beginning of pixel data to correlate with the 
trailing edge of the sample clock signal, As such, the next 
rising edge of the sample clock signal will be at the center 
of the period in which the blue signal (and the red and green 
signals) hold valid data. 

In an alternate embodiment, additional smoothing logic 
(either hardware or software) is used to slow down the 
changes in phase. Rather than toggling between shifting 
forward and shifting backward, at each sample, the logic can 
decide to forego a change after a status read. In order to 
decide when to change, a running average (or other filtering 
function) can be used to determine the effect of changing or 
not changing. 

The A-to-D/PLL also has a number of internal registers 
that allow the board to have control over the phase relation- 
ship of the input signals and the output clock signal. This 
allows adjustments to be made on the sampling clock to 
ensure that the input signal is sampled on the optimal 
location and minimize jitter caused by sampling during 
transition. It also has settings for adjusting the voltage level 
offset and gain to allow for adjustment due to level shifting 
and attenuation over the video cable. In the preferred 
embodiment, the A-to-D/PLL is the Philips TDA8752H/ 
8 — a triple high-speed (100 MHz) analog to digital con- 
verter. It contains all of the phase-locked -loop circuitry 
necessary to generate the pixel clock from the Horizontal 
Sync signal. The TDA8752 has numerous control registers 
that are set by the microcontroller via an 12 C interface. 

One set of possible resolutions that can be used by the 
present invention is shown in Table I below. 
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TABLE I 

COMMON VIDEO MODES DEFINED 

PCLK 



Resolution 


Vert. Freq. 


Horiz. Freq. 


Lines/Frame 


PixeJs/Line 


H/V Level Modulus 


PCLK Freq. 


DOS 


70 Hz 


31.5 KHz 


450/??? 


???/??? 


LOW/HIGH 




640x480-60 


60 Hz 


31.5 KHZ 


480/525 


640/800 


LOW/LOW 


25.175 MHz 


640x480-72 


72 Hz 


37.9 KHz 


480/520 


640/832 


LOW/LOW 


31.500 MHz 


640x480-75 


75 Hz 


37.5 KHz 


480/500 


640/840 


LOW/LOW 


31.500 MHz 


640x480-85 


85 Hz 


43.3 KHz 


480/509 


640/832 


LOW/LOW 


36.000 MHz 


800x600-56 


56 Hz 


35.1 KHz 


600/625 


S00/1024 


HIGH/HIGH 


36.000 MHz 


800x600-60 


60 Hz 


37.9 KHz 


600/628 


800/1056 


HIGH/HIGH 


40.000 MHz 


800x600-72 


72 Hz 


48.1 KHz 


600/666 


800/1040 


HIGH/HIGH 


50.000 MHz 


800x600-75 


75 Hz 


46.9 KHz 


600/625 


800/1056 


HIGH/HIGH 


49.500 MHz 


800x600-85 


85 Hz 


53.7 KHz 


600/631 


800/1048 


HIGH/HIGH 


56.250 MHz 


1024x768-60 


60 Hz 


48.4 KHz 


768/806 


1024/1344 


HIGH/HIGH 


65.000 MHz 


1024x768-70 


70 Hz 


56.5 KHz 


768/806 


1024/1328 


HIGH/HIGH 


75.000 MHz 


1024x768-75 


75 Hz 


60.0 KHz 


768/800 


1024/1312 


HIGH/HIGH 


78.750 MHz 


1024x768-85 


85 Hz 


68.7 KHz 


768/808 


1024/1376 


HIGH/HIGH 


94.500 MHz 



As would be appreciated by one of ordinary skill in the art, 
other resolutions are possible. The determination of other 
possible modes may be aided by reference to VESA and 
Industry Standards and Guidelines for Computer Display 
Monitor Timing, version 1.0, Revision 0.7, Revision Date: 
Dec. 18, 1996, the contents of which are incorporated herein 
by reference. 

In addition to the above factors used to control video 
modes, the system of the present invention also controls 
when sampling begins following an (P)HSYNC signal or a 
VSYNC signal. The time from signal to first sample is called 
the "front porch." If sampling after an (P)HSYNC signal 
begins too early (i.e., the front porch is too short), the system 
will sample "black" pixels prior to the real left edge of the 
display. If sampling after an HSYNC signal begins too late 
(i.e., the from porch is too long), the system will miss 
sampling the beginning pixels of the display. Similar prob- 
lems exist for timing with relation to the VSYNC signal. 
Accordingly, the present invention provides the ability to set 
the front porch. 

In one embodiment of the present invention, the front 
porch is set manually through user intervention — typically 
through a trial and error process. In three automated 
embodiments, the system of the present invention provides 
automatic determination of the front porch when a non-black 
background is used. In the first automated embodiment, the 
right edge of the screen is used as a reference. Thus, the 
system uses an initial front porch value, counts out the 
number of pixels in a row, and then determines if the pixel 
after the end of the row is black or colored. If that pixel is 
black using the initial front porch value, then the front porch 
value is shortened and the counting process is repeated. This 
shortening process is repeated until a non-black pixel is 
found in iteration I. Then the front porch value is reverted to 
the front porch value in iteration 1-1 — i.e., to the front porch 
value in the previous iteration. On the contrary, if the pixel 
is colored when using the initial front porch value, then the 
front porch value is increased until a black pixel is found at 
the end of a row in iteration I. The front porch value is then 
reverted to the delay value in iteration 1-1 — i.e., to the front 
porch value in the previous iteration. 

In the second automated embodiment, a process similar to 
the first automated embodiment is used, except that the 
beginning of the row is analyzed. If the beginning of the row 
is found to be black, then the front porch value is increased 
until a non-black pixel is found in iteration I. Conversely, if 
the beginning of the row is found to be colored, then the 



20 

front porch value is decreased until a black pixel is found in 
iteration I. Then the front porch value is reverted to the front 
porch value in iteration 1-1. 

In a third automated embodiment, the processes of the 

25 first and second automated embodiments are combined — 
thereby checking the left and right edges. In this manner, the 
correct number of pixels per line can also be automatically 
determined. A similar process can be performed for the 
vertical delay looking at (1) the top row, (2) the bottom 

30 column, or (3) the top and bottom columns. 

The Flash memory components) contains all n on- volatile 
data required to enable the onboard microprocessor to 
control operation of the intelligent digitizer 75. Flash infor- 
mation includes: (1) Microprocessor Program/Backup/Boot 

35 code and (2) a PCI FPGA Initialization Bitstream. If suffi- 
cient free memory space exists on the Flash, then the Flash 
also contains backup copy of the last correctly programmed 
PCI FPGA Initialization Bitstream. This enables the digi- 
tizer 75 to be reloaded in case of an error in programming. 

40 One embodiment of the Flash configuration uses one PLCC 
Flash device with a TSOP Flash device soldered on the 
board. 

In one embodiment of the Flash memory device, the 
memory is physically addressed as a single large memory 

45 device. In an alternate embodiment, the memory is physi- 
cally divided into pages that can be used as the micropro- 
cessor decides. By setting the page bits in a page register, the 
system can change from one page to another. For example, 
using two page bits, 00=page 0, 01=page 1, 10=page 2, and 

50 ll=page 3. As the number of page bits increases, the number 
of independently addressable pages increases. This aids in 
providing a larger accessible memory to those microproces- 
sors that have small address bus sizes. 

The SRAM component contains both User Data to be 

55 used for general purpose RAM and program data when the 
microprocessor needs to run the program from RAM. In one 
embodiment of the SRAM memory device, the memory is 
physically addressed as a single large memory device. In an 
alternate embodiment, the memory is physically divided into 

60 pages as described above. 

The CPU Interface CPLD is intended to provide all of the 
CPU's address/data bus interfacing signals including the 
chip selects to memory, the FPGA, and any external signals 
that need to be read from MMIO. By way of a non-limiting 

65 example, the FPGAs, CPLD and SDRAM run off a 3.3 volt 
power supply. The other components may use the same or 
different supply voltages. 
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The PCI FPGA provides the communication interface 
between the CPU of the computer and the local micropro- 
cessor 700 onboard the controller 50. Thus, the PCI FPGA 
receives requests sent by the device driver 210. It also 
provides access to the video buffer and supporting registers 5 
(e.g., bit change, block status). Although depicted as an 
FPGA, one of ordinary skill in the art would appreciate that 
the communication interface also can be either an applica- 
tion specific integrated circuit (ASIC) or a one-time pro- 
grammable (OTP) circuit if the interface does not need to be 10 
field updated. The interface provides the following features 
(through the device driver 210): (1) re-programming the 
CPLD over a JTAG interface; (2) detecting video presence; 
(3) detecting video resolution parameters; (4) intializing the 
frame buffer; (5) polarizing sync signals; (6) controlling the 35 
Video DSP FPGA; (7) resetting the components of the 
controller 50; and (8) setting the active video parameters. 

The Video DSP FPGA performs most of the video signal 
processing required to capture, filter, detect changes in 
frames, and store the video in a frame buffer (e.g., a 20 
SyncDRAM memory device). The PCI FPGA controls 
operation of the video DSP including any modes that the 
video DSP has for capturing video . 

By providing separate programming interfaces for the two 
FPGAs, the video DSP FPGA can be updated without 25 
reprogramming the PCI interface that interfaces directly 
with the PCI bus. 

The microprocessor of the controller controls most of the 
local data flow on the controller 50. That microprocessor 
performs: (1) Basic system testing (e.g., code checking, 30 
FPGA checking, and RAM testing), (2) transferring mouse 
and keyboard signals, (3) downloading new programs or 
FPGA boot code; (4) initializing the onboard FPGAs; and 
(5) communicating with the analog-to-digital converter to 
control pixel clock settings (e.g., phase and frequency) and 35 
video settings (e.g., color offsets). The microprocessor may 
act as a watchdog timer to ensure that the system is running 
properly. If the system is not running properly, the micro- 
processor can then reset the system. 

When the controller is first powered on, a power-on reset 40 
is performed internally by the CPU. (The RESET pin is held 
low at power-up by a pull-down resistor until the FPGA is 
booted. Once booted, the FPGA will drive the signal low 
unless a reset is asserted by the application). Later, the 
controller 50 may be reset by receiving a command from the 45 
communication interface. This signal forces a hardware 
reset to the microprocessor and resets the CPU and all 
registers to a known state. The controller 50 may be partially 
or completely reset by using commands to perform: (1) a 
CPU reset, (2) a CPLD reset, or (3) a video DSP reset. The 50 
CPU Reset resets the CPU and the CPLD interface logic to 
the CPU. This allows the application to set the CPU and any 
logic that will affect the operation of the CPU to a known 
and initial state. In addition, the CPU may have the capa- 
bility through independent logic to cause a self-reset. 55 

The CPLD reset resets the additional circuitry that does 
not interface to the CPU. The logic that allows the CPU to 
reset itself functions independently from the interface logic. 
In addition, the Video DSP Reset allows either the applica- 
tion or CPU to reset the internal logic of the Video DSP 60 
FPGA to either recover from a locked-up or to re-initialize 
any internal logic that needs to be set to a known state. 
Preferably, all of the reset signals are active high and are 
tri-stated with a pull-down resistor. This allows multiple 
sources to signal a reset without causing contention. An 65 
active high reset provides consistency with the CPU's reset 
polarity. 
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When the controller 50 determines that the target device 
is a target switch rather than a target computer, the controller 
can provide additional functionality specific to the switch. 
The controller can provide "thumbnail" images of target 
computers connected to a target switch to allow many target 
systems to be displayed at the same time, shown in minia- 
ture. 

The control applications (220 and 240) utilize a multi- 
window architecture (e.g., the Multiple Document Interface 
(MDI)) to support control for multiple target devices. When 
a target computer's window gains focus, the target controller 
50 automatically sends the appropriate keystroke sequence 
(e.g., "<PrtScr>+number+<Enter>") to the switch to select 
the corresponding switch port of that target computer. When 
the mouse and keyboard have been inactive for a specified 
time interval, the controller will optionally enter a scan 
mode. In this mode, the target-system windows are updated 
in a repeating sequence. To update each of the target 
computers, the controller card sends a switch command (i.e., 
a keystroke sequence (e.g., "<PrtScr>+number+<Enter>")) 
to select the next target device. The video output of that 
target device is then sampled, and the sampled image is 
written using GDI calls. Any mouse or keyboard activity 
cancels scan mode, and only the selected target window 
continues to be updated. 

In one embodiment of the system of the present invention, 
the user (with the help of a configuration file or configuration 
"wizard") manually establishes the correlation between the 
name of a system and its switch/port number. In light of the 
fact that this manual process can be cumbersome, especially 
when switched are tiered in a hierarchy, an alternate embodi- 
ment utilizes an automated configuration process. In that 
embodiment, the switches utilize one of the keyboard or 
mouse ports or a separate dedicated communications port to 
pass information from the target devices or switches up to 
the target controller 50. In yet another embodiment, the 
target controller 50 receives configuration information from 
a network computer about the port/switch configurations. 

In a more secure embodiment, the present invention 
includes security features to restrict the computers that can 
be viewed or accessed (or both) by the remote control 
software. For example, using this security, one user may 
only be able to view target computers on switch ports 1 and 
3 while another user can view and interact with computers 
on switch ports 1 and 2. In this manner, the system of the 
present invention can provide monitoring capabilities to less 
trusted individuals and full access to other, trusted individu- 
als. 

In an alternate embodiment, two or more different users 
may connect to the same controller 50. In this embodiment, 
the two or more users may control different controller cards 
or may share access to the same controller card. In this 
embodiment, the captured GDI calls for a controller card are 
routed to the appropriate remote control software. Likewise, 
a user may be connected to multiple controller cards on one 
or more computers simultaneously. In that case, the user can 
monitor and control several target devices simultaneously. 

Additional processing performed by the intelligent digi- 
tizer 75 is the analysis of the blocks. As shown in FIG. 7a, 
the system maintains at least two status bits per block, 
although other status bits are also possible. The first status 
bit indicates which blocks have changed (either with or 
without filtering). This bit acts as a "dirty" bit in a cache. 
This bit can be separated into two bits if the system is to 
track which blocks have changed at all versus which blocks 
have changed more than the threshold. This threshold may 
be (1) global for the whole screen or (2) specific to particular 
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blocks. Moreover, this threshold may be updated dynami- 
cally either (1) at a user's request or (2) in response to an 
automatic adjustment of parameters to change performance 
characteristics. 

The second bit illustrated indicates whether the corre- 5 
sponding block is a single color. As described above, if the 
block is a single color, then the block can be compressed by 
redrawing the block as a single GDI call, as discussed above. 

As also discussed above, blocks can be compared for 
similarity to other blocks. Although not shown in the status 10 
fields of FIG. la, the status fields can include a reference to 
another block to which the current block is equal. 

FIG. lb shows a memory area that can be read by the 
microprocessor of the controller to determine which blocks 
have changed or are a single color. If additional bits of status is 
information per block were used, the entry for each block 
would be widened by that number of bits. 

In addition to indicating whether a block has changed, the 
intelligent digitizer 75 can also, in hardware, track which 
pixels within a block have changed. When tracking which 20 
pixels have changed, a memory area, as shown in FIG. 8, is 
assigned to each block. The analyzing digitizer control 
application 240 can then read from memory the changed bits 
and determine if individual pixels should be redrawn of if 
the block should be redrawn in its entirety. By reading the 25 
first 32 bits of that memory and comparing with zero, the 
system can determine if any pixels in that line have changed. 
If not, the next line can be processed. In an alternate 
embodiment, the hardware contains a separate register for 
each block which identifies which lines within the block 30 
have changed. In this way, the system can quickly identify 
the lines that contain changed pixels. 

Although the above description has focused on the normal 
operation of the present invention, the processing of the 
system may be paused when a user is temporarily uninter- 35 
ested in the changes on the target device. The analyzing 
digitizer control application 240 freezes its status in 
response to a message from the controlling computer. If the 
user has minimized the screen representing the target device 
on the monitor of the controlling computer 12, then real-time 40 
updates of changes to the screen are not necessary. The 
internal buffers of the controller 50 that represent the last 
screen sent to the controlling computer 12 are no longer 
updated — i.e., they are frozen. However, the buffers repre- 
senting the sampled video signals from the target device 45 
continue to be overwritten. The system then continues to 
track which blocks have changed in comparison to the 
frozen blocks — not in comparison to a previously sampled 
blocks. When the screen is re-enlarged, the controller 50 is 
unfrozen and the changes are sent back to the controlling 50 
computer 12. 

Thus, until the screen is un-minimized, the bandwidth that 
would have been used to send the changes (which would not 
have been seen) is saved. This is especially important when 
simultaneously monitoring multiple target devices over a 55 
lower-bandwidth modem connection. This method of per- 
forming comparison with the frozen blocks still allows the 
analyzing digitizer control application 240 to inform the 
controlling computer 12 of how many blocks have 
changed — without having to send those changes. Thus, the 60 
minimized icon on the controlling computer that represents 
the target device may flash or an audio signal may be played 
to inform the user that a major change to the screen has 
occurred. 

In light of the inherent delay in the transmission process, 65 
the digitized mouse pointer on a target computer may be 
updated too slowly to allow accurate control of the mouse. 
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As a result, the controlling computer 12 generates a pseudo- 
cursor (e.g., a set of cross-hairs) that indicates where the 
digitized cursor should be. To initialize this process, the 
digitizer control application 220 (or the analyzing digitizer 
control application 240) sets the cursor of the target com- 
puter to a known location. For example, by sending to the 
target computer a series of mouse commands, it is possible 
to drive the cursor to the upper left hand-comer (the 0,0 
comer), no matter where the cursor was prior the series of 
commands. The original cursor is then forced back down to 
be aligned with the cross-hairs. 

As the mouse commands are received by the digitizer 
control application 220 (or the analyzing digitizer control 
application 240), they are processed and passed on to the 
target device (which updates its local cursor). In order to 
avoid overloading the target computer with mouse packets, 
the digitizing control application 220 can queue mouse 
commands and end those mouse commands as a group. 
Alternatively, the digitizer control application 220 (or the 
analyzing digitizer control application 240) can completely 
filter out a series of mouse movement events. To reproduce 
the effect that the filtered commands would have had, the 
system periodically samples the mouse position and sends, 
to the target controller, a mouse movement command rep- 
resenting the difference between the new position and the 
previous mouse position. 

If the mouse pointer generated at the target controller 50 
ever becomes out of alignment with the pointer generated on 
the target computer, the user can reset the pointers using a 
hot-key. Like during initialization, the target computer ig 
then sent a series of mouse commands to move the pointer 
to a known location and then from the known location to the 
position consistent with the cross-hairs drawn by the digi- 
tizer control application 220 (or the analyzing digitizer 
control application 240). When the window of the digitizing 
control application 220 has the focus, this 
re-synchronization process is also performed when the 
mouse enters an active window of the digitizer control 
application 220 (or the analyzing digitizer control applica- 
tion 240). 

The above discussion has described the present invention 
in terms of remote control software 200 and an analyzing 
digitizer control application 240 that are separate software 
programs. In an alternate embodiment, the functionality of 
those two programs is more tightly integrated — either 
through the use of an API to communicate between them, or 
by combining the two into a single application. In this tighter 
integration, the analyzing digitizer control application 240 
can transmit the changed blocks to the remote control 
software 200 in either compressed or uncompressed format. 
One example of a compressed format is a differential format 
in which a change flag indicates whether or not each pixel 
(or line) has changed. Then, the compressed block includes 
only the values within the block that have changed. Thus, the 
number of bytes to transmit is reduced as long as the 
overhead of the flags is less than the number of bytes saved 
by not transmitting those unchanged pixels in the block. 

One implementation of such a compression header is 
shown in FIG. 9a. The header consists of 32 words that are 
each 32 bits — one bit for each pixel. As shown in the first 
line, three pixels in the first 32 pixels are changed. No other 
pixels in blocks 2-31 are changed, but in the last line, one 
additional pixel has changed. The data for the four pixels 
then follows the header. 

A second implementation of the compression header 
utilizes a block header which indicates which lines have 
changed. The header indicates that only the first and last 
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lines have changed, so the bit flags for those lines are 
included — without including the bit flags for the unchanged 
lines. 

Another compression technique used in an alternate 
embodiment includes encoding a block as (1) a reference to 5 
a known block (not necessarily the block from the previous 
screen capture) and (2) the changes that must be made to the 
referenced block in order to generate the current block. For 
example, if the background of an application changes, then 
all blocks identified as part of the background can be 
changed by simply referencing the first background block. If 
a portion of the block was not background, then only those 
parts that are not the background need to be encoded in the 
block. This technique similarly works for blocks that are 
almost completely one color. The block is simply encoded as 
(1) the background color of the block and (2) those pixels 
that are different from the background color. 

In an alternate embodiment, in order to provide even 
further compression, blocks are compressed using intra- 
block compression. For example, a block may be com- 2Q 
pressed using run-length coding (with or without end-of- 
block markers) or Ziv-Lempel- Welch (LZW) encoding. 

Although the target controller 50 has been described 
above as performing only the screen capture functions, that 
target controller 50 can provide additional functionality as 25 
well. The digitizer control application 220 and the analyzing 
digitizer control application 240 can be minimized so that 
the user can access the other programs stored on the target 
controller 50. As such, the target controller 50 can be used 
to configure the network, cycle power to individual com- 3Q 
puters (20fl to 20c) and any other function that can be 
performed on computer to which a user is connected. It is 
even possible that the target controller 50 be connected to 
one of the switches that it samples. 

In yet another embodiment of the present invention, the 35 
system captures outputs to a digital display rather than an 
analog display. In that embodiment, it is not necessary to 
convert from analog to digital format. The system simply 
buffers and analyzes the video data as if it were sampled 
data. 

Obviously, numerous modifications and variations of the 
present invention are possible in light of the above teach- 
ings. It is therefore lo be understood that, within the scope 
of the appended claims, the invention may be practiced 
otherwise than as specifically described herein. 

What is claimed is: 

1. A target controller for remotely controlling at least one 
of an external target switch and an external target computer, 
the controller comprising: 

an analog video interface for receiving analog video 50 
signals from the at least one of an external target switch 
and an external target computer; 

a digitizer for digitizing the analog video signals received 
from the analog video interface; 

a microprocessor; 55 

a memory comprising plural computer code devices 
including: 

a first computer code device configured to divide the 
digitized video signals into blocks of digitized video; 

a second computer code device configured to compare 60 
a first block from a first frame to a second block from 
a subsequent frame; and 

a third computer code device configured to send only 
pixel values that changed between the first and 
second blocks. 65 

2. The controller as claimed in claim 1, wherein the third 
computer code device comprises a fourth computer code 
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device configured to detect if all pixels in a block are a single 
color such that the block can be redrawn using a single GDI 
call to fill a block. 

3. The controller as claimed in claim 1, wherein the 
second computer code device comprises a fourth computer 
code device configured to filter each block before determin- 
ing if the block has changed. 

4. The controller as claimed in claim 3, wherein the fourth 
computer code device comprises a fifth computer code 
device configured to utilize a percentage threshold, wherein 
the block is not designated as changed if a number of 
changed pixels within the block is less than the percentage 
threshold. 

5. The controller as claimed in claim 3, wherein the fourth 
computer code device comprises a fifth computer code 
device configured to utilize an intensity threshold, wherein 
the block is not designated as changed if a pixel having a 
maximum change within the block has a change less than the 
intensity threshold. 

6. The controller as claimed in claim 3, wherein the fourth 
computer code device configured to filter each block com- 
prises a fifth computer code device configured to dynami- 
cally change a filter used by the fourth computer code 
device. 

7. The controller as claimed in claim 1, wherein the 
analog video interface receives analog video signals from an 
external target switch, and wherein the first computer code 
device comprises a fourth computer code device configured 
to switch a current connection of the external target switch 
such that the analog video signals change from a first 
computer to a second computer. 

8. The controller as claimed in claim 7, further compris- 
ing: 

a fifth computer code device configured to capture a 
mouse click and correlate the mouse click to one of 
plural windows; and 

is a sixth computer code device configured to convert the 
mouse click into a series of switch commands that 
switch the external target switch to an external target 
computer corresponding to the one of plural windows. 

9. The controller as claimed in claim 1, further compris- 
ing: 

one of a keyboard interface and a mouse interface; and 
a fourth computer code device configured to send a 
command received from the one of a keyboard inter- 
face and a mouse interface to the at least one of an 
external target switch and an external target computer. 

10. The controller as claimed in claim 1, further compris- 
ing: 

an integrated keyboard and mouse interface; and 
a fourth computer code device configured to send a 
command received from the integrated keyboard and 
mouse interface to the at least one of an external target 
switch and an external target computer. 

11. The controller as claimed in claim 1, wherein the first 
computer code device comprises a fourth computer code 
device configured to dynamically change a size of the blocks 
of the digitized video. 

12. The controller as claimed in claim 1, wherein the third 
computer code device comprises a fourth computer code 
device configured to compress the changed pixel values. 

13. The controller as claimed in claim 1, wherein the 
fourth computer code device comprises a fifth computer 
code device configured to change a compression technique 
used by the fourth computer code device. 

14. The controller as claimed in claim 1, wherein the first 
computer code device comprises a fourth computer code 
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device configured to automatically determine a resolution of 
the analog video signals. 

15. The controller as claimed in claim 14, wherein the 
fourth computer code device further comprises a fifth com- 
puter code device configured to determine a delay to be used 5 
before sampling each line of video signals. 

16. The controller as claimed in claim 1, further compris- 
ing a fourth computer code device configured to detect a 
phase of the analog video signals based on signal jitter and 

to sample the analog video signals at substantially 180 10 
degrees out of phase to the signal jitter. 

17. The controller as claimed in claim 1, further compris- 
ing a fourth computer code device configured to track mouse 
movements and output a pseudo-cursor independent of a 
digitized cursor. 15 

18. The controller as claimed in claim 17, further com- 
prising a fifth computer code device configured to align the 
pseudo-cursor and the digitized cursor. 

19. The target controller as claimed in claim 1, wherein 
the external target switch comprises a KVM switch. 20 

20. A target controller for remotely controlling at least one 
of an external target switch and an external target computer, 
the controller comprising: 

an analog video interface for receiving analog video 
signals from the at least one of an external target switch 25 
and an external target computer; 

a digitizer for digitizing the analog video signals received 
from the analog video interface; 

a first logic device configured to divide the digitized video 
signals into blocks of digitized video; 
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a second logic device configured to compare a first block 
from a first frame to a second block from a subsequent 
frame; and 

a third logic device configured to send only pixel values 
that changed between the first and second blocks. 

21. The controller as claimed in claim 20, wherein the 
first, second, and third logic devices are implemented as 
reconfigurable logic devices in a field programmable gate 
array. 

22. The target controller as claimed in claim 20, wherein 
the external target switch comprises a KVM switch. 

23. A target controller for remotely controlling at least one 
of an external target switch and an external target computer, 
the controller comprising. 

an analog video interface for receiving analog video 
signals from the at least one of an external target switch 
and an external target computer; 

a digitizer for digitizing the analog video signals received 
from the analog video interface; 

first means for dividing the digitized video signals into 
blocks of digitized video; 

second means for comparing a first block from a first 
frame to a second block from a subsequent frame; and 

third means for sending only pixel values that changed 
between the first and second blocks. 

24. The target controller as claimed in claim 23, wherein 
the external target switch comprises a KVM switch. 
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Evidence Appendix 

Other than the reference attached to the Appeal Brief as Appendix B, no evidence was 
submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132, and no other evidence was entered 
by the Examiner and relied upon by Appellant in the Appeal. 
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JERRY SMITH, Administrative Patent Juda^ . 



DECISION ON APPF1AT, 



This is a decision on the appeal under 35 U.S.C. § 134 
from the examiner's rejection of claims 1-21, which constitute 
all the claims in the application. 

The disclosed invention pertains to a method and 
apparatus for communicating information between a management card 



and first and second interface cards 



coupled to the management 
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card. A client identifies an interface card or a network device 
associated with the interface card, and a communication link 
between the client and a particular one of the first and second 
interface cards is established in response to the interface card 
identified by the client. 

Representative claim 1 is reproduced as follows: 

1. A system for communicating management 
information, comprising: 

a first interface card; 

a second interface card; and 

a management card coupled to the first interface 
card and the second interface card, the management card 
operable to: 

receive a command from a client, the command 
identifying an interface card or a network device 
associated with an interface card; 

establish a communication link between the client 
and a particular one of the first interface card and the 
second interface card selected in response to the command 
communicated by the client; and 

communicate "management information using the 
communication link . 



The examiner relies on the following references: 



Flood et al. (Flood) 
Schneider et al . (Schneider) 



4, 937, 777 
6, 304, 895 



Jun. 26, 1990 
Oct. 16, 2001 
(filed Jul. 23, 1999) 
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Claims 1, 4-7, 10-14, 16 and 18-21 stand rejected under 
35 U.S. C. § 102(e) as being anticipated by the disclosure of 
Flood. Claims 2, 3, 8, 9, 15 and 17 stand rejected under 
35 U.S.C. § 103(a) as being unpatentable over the teachings of 
Flood in view of Schneider. 

Rather than repeat the arguments of appellant or the 
examiner, we make reference to the briefs and the answer for the 
respective details thereof. 

OPINION 

We have carefully considered the subject matter on 
appeal, the rejections advanced by the examiner and the evidence 
of anticipation and obviousness relied upon by the examiner as 
support for the rejections. We have, likewise, reviewed and 
taken into consideration, in reaching our decision, the 
appellant's arguments set forth in the briefs along with the 
examiner's rationale in support of the rejections and arguments 
in rebuttal set forth in the examiner's answer. 

It is our view, after consideration of the record before 
us, that the evidence relied upon supports the examiner's 
rejection of claims 1, 2, 4-8, 10-16 and 18-21, but the evidence 
does not support the rejection of claims 3, 9 and 17. 
Accordingly, we af f irm-in-part . 
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We consider first the rejection of claims 1, 4-7, 10-14, 
16 and 18-21 under 35 U.S.C. § 102(e) as being anticipated by 
Flood. Appellant has indicated that claims 1, 4, 5, 7, 10-12, 
14, 16, 18, 19 and 21 stand or fall together as a first group, 
and claims 6, 13 and 20 stand or fall together as a second group 
(brief, page 5) . Consistent with this indication appellant has 
made no separate arguments with respect to any of the claims on 
appeal within each group. Accordingly, all the claims within 
each group of claims will stand or fall together. Note In re 
Kj -nq, 801 F.2d 1324, 1325, 231 USPQ 136, 137 (Fed. Cir. 1986); In 
re Sernaker, 702 F.2d 989, 991, 217 USPQ 1, 3 (Fed. Cir. 1983). 
Therefore, we will consider the anticipation rejection against 
claims 1 and 6 as representative of all the claims rejected on 
anticipation . 

With respect to independent claim 1, the examiner has 
indicated how he finds the claimed invention to be fully met by 
the disclosure of Flood (answer, page 4) . Appellant argues that 
given the elements identified by the examiner, Flood fails to 
disclose a management card operable to receive a command from a 
client as claimed. Appellant also argues that nowhere does Flood 
state that its command identifies an interface card or a network 
device associated with an interface card as claimed. Appellant 
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additionally argues that Flood fails to disclose that the 

management card is operable to establish a communication link 

between the client and a particular one of the interface cards in 

response to the command from the client. Appellant asserts that 

connections provided by cables 2 5 and 2 6 in Flood are not in 

response to a command communicated by the client (brief, pages 7- 
10) . 

The examiner responds that Flood teaches that a central 
host computer can program and control the operation of a 
plurality of programmable controllers. The examiner notes that 
the claimed commands from a client are met by the programming 
instructions from a user in Flood. The examiner also notes that 
system controller 16 in Flood is connected to the programming 
terminal to receive user programs (answer, pages 9-11) 

Appellant responds that the programming instructions of 
Flood have nothing to do with identifying an interface card or a 
network device associated with an interface card as claimed. 
Appellant argues that, instead, the programming instructions of 
Flood are used for programming and controlling a plurality of 
programmable controllers. Appellant argues that the examiner is 
relying on two different portions of Flood to teach the claimed 
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command. Appellant repeats his position that system controller 
16 of Flood cannot be the management card and meet the 
recitations of claim 1 (reply brief, pages 2-5) . 

We will sustain the examiner's rejection of 
representative claim 1 and of the other claims grouped therewith. 
Although the examiner has not properly identified what elements 
of Flood correspond to the claimed first interface card, second 
interface card and management card, it appears from the record 
that the first and second interface cards can be any of the 
processors 18 or scanners 20, and the management card corresponds 
to the system controller 16. It is clear that system controller 
16 of Flood is coupled to each of the processors 18 and scanners 
20. Claim 1 recites that the management card (system controller 
16) receives a command from a client identifying an interface 
card or network device associated with an interface card. Flood 
meets this recitation because system controller 16 receives 
commands from a client (24) which identify the programable 
controller to which they are intended. The management card 
(system controller 16) in Flood establishes a communication link 
to the designated controller so that the programs and commands 
from terminal 24 can be downloaded to the appropriate controller. 
Finally, Flood meets the final step of claim 1 because the system 
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controller 16 uses the established link to communicate management 
information between the terminal 24 and the designated 
programmable controller. Note that each of the execution 
processors of Flood is individually loaded with user control 
programs (column 5, lines 1-5) . 

Although we have given careful consideration to 
appellant's arguments in the briefs, it appears to us that 
appellant has not fully grasped the manner in which the examiner 
has read claim 1 on the disclosure of Flood. Although appellant 
argues that system controller 16 receives no command, it is clear 
to us that system controller 16 receives a command from terminal 
24 indicating which programmable controller is to be accessed by 
the system controller. Although cable 25 is not connected in 
response to a command, the appropriate connection along the 
control, data and address lines 21-23 between the system 
controller 16 and the designated programmable controller is made 
in response to the commands received on cable 25 from the client. 
We find that this operation meets the recitations of claim 1. In 
other words, individual communication links are established 
between system controller 16 and execution processors 18 on lines 
21-23 in response to requests made by the client at terminal 24. 
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With respect to representative claim 6, the examiner has 
indicated how he reads the claimed invention on the disclosure of 
Flood (answer, page 5). We note that appellant grouped claims 6, 
13 and 20, which are rejected under 3 5 U.S. C. § 102, with claims 
3, 9 and 17, which were rejected under 35 U.S.C. § 103. 
Appellant has only addressed the limitations of claim 3 and has 
not made arguments with respect to the limitations of claim 
6 even though claim 6 is broader than claim 3. Since claims 6, 
13 and 2 0 each recites a limitation which has not been argued by 
appellant, these claims stand or fall with the claim from which 
they each respectively depend. Since we have sustained the 
rejection with respect to each of the parent claims, we also 
sustain the rejection of claims 6, 13 and 20. 

We now consider the rejection of claims 2, 3, 8, 9, 15 
and 17 under 3 5 U.S.C. § 103 based on the teachings of Flood and 
Schneider. In rejecting claims under 3 5 U.S.C. § 103, it is 
incumbent upon the examiner to establish a factual basis to 
support the legal conclusion of obviousness. See In re Fine . 837 
F.2d 1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). In so 
doing, the examiner is expected to make the factual 
determinations set forth in Graham v . John Deere Co . , 3 83 U.S. 1, 
17, 148 USPQ 459, 467 (1966), and to provide a reason why one 
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having ordinary skill in the pertinent art would have been led to 
modify the prior art or to combine prior art references to arrive 
at the claimed invention. Such reason must stem from some 
teaching, suggestion or implication in the prior art as a whole 
or knowledge generally available to one having ordinary skill in 
the art. Uniroval, Inc. v. Rudkin-Wilev Corp. , 837 F.2d 1044, 
1051, 5 USPQ2d 1434, 1438 (Fed. Cir . ) , cert, denied , 488 U.S. 825 
(1988) ; Ashland Oil, Inc. v. Delta Resins & Refractories, Inc. , 
776 F.2d 281, 293, 227 USPQ 657, 664 (Fed. Cir. 1985), cert. 
denied, 475 U.S. 1017 (1986); ACS Hosp. Svs . , Inc. v. Montefiore 
Hoso. , 732 F.2d 1572, 1577, 221 USPQ 929, 933 (Fed. Cir. 1984). 
These showings by the examiner are an essential part of complying 
with the burden of presenting a prima facie case of obviousness. 
Note In re Oetiker , 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 
(Fed. Cir. 1992) . If that burden is met, the burden then shifts 
to the applicant to overcome the prima facie case with argument 
and/or evidence. Obviousness is then determined on the basis of 
the evidence as a whole and the relative persuasiveness of the 
arguments. See Id. ; In re Hedges , 783 F.2d 1038, 1039-40, 228 
USPQ 685, 686 (Fed. Cir. 1986); In re Piasecki , 745 F.2d 1468, 
1472, 223 USPQ 785, 788 (Fed. Cir. 1984); and In re Rinehart . 531 
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'F.2d 1048, 1052, 189 USPQ 143, 147 (CCPA 1976). Only those 
arguments actually made by appellant have been considered in this 
decision. Arguments which appellant could have made but chose 
not to make in the brief have not been considered and are deemed 
-to be waived ( see 37 CFR § 41.37 (c) (1) (vii) (2004) ) . 

Appellant has indicated that claims 2, 8 and 15 stand or 
fall together as a single group (brief, page 5) . The examiner 
has indicated how he finds the invention of these claims to be 
unpatentable (answer, pages 6-8) . Appellant argues that the 
examiner has failed to identify which components in Schneider 
correspond to the management card, the switch, the processor and 
the memory of claim 2. Appellant also argues that switches 74a 
and 74b do not form part of a management card, and the 
combination fails to teach the various elements as claimed 
(brief, pages 10-11) . 

The examiner responds that Schneider teaches how a 
plurality of users may control different cards and how different 
switch ports are" selected (answer, pages 11-12). Appellant 
responds that switches 74a and 74b of Schneider do not form part 
of a management card and there is no teaching of a mapping to a 
first port and a second port (reply brief, page 5) . 
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We will sustain the examiner's rejection of claims 2, 8 
and 15. The examiner has cited Schneider to teach the claimed 
manner in which communication links are established between a 
client and a port. The examiner has explained in some detail how 
the configuration wizard in Schneider would have led the artisan 
to map specific communications in Flood to the appropriate port 
in the management card. Appellant has not addressed the specific 
explanation offered by the examiner but has simply asserted that 
elements 74a and 74b of Schneider do not meet the claimed 
invention. We can find nothing in the examiner's explanation 
which suggests that the examiner has relied on these elements to 
support his position. 

Since the examiner appears to have established a prima 
facie case of the obviousness of claims 2, 8 and 15, and since 
appellant's arguments do not convince us that the rejection is in 
error, we sustain the rejection of these claims as noted above. 

Although appellant nominally grouped claims 3, 9 and 
17 with claims 6, 13 and 20, these claims are substantially 
different and were rejected on a different basis as discussed 
above. We will consider these claims separately because 
appellant argued them and bee ause the examiner responded to the 
arguments with respect to these claims. The examiner's rejection 
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of these claims is set forth on page 9 of the answer. Appellant 
argues that the cited portions of Flood have nothing to do with 
the claimed processor which is operable to configure the 
management information for the operating system of the network 
device associated with the particular interface card. Appellant 
notes that Flood does not even remotely consider different 
operating systems (brief, pages 11-12). The examiner responds 
that the artisan would have understood that the first and second 
network devices of Flood use first and second operating systems 
(answer, page 13) . Appellant responds that there is no basis to 
conclude that Flood teaches the limitations of claim 3 . 
Appellant notes that the Flood-Schneider combination does not 
even discuss operating systems or different operating systems 
associated with different network devices (reply brief, page 5) . 

We will not sustain the examiner's rejection of claims 3, 
9 and 17 for essentially the reasons argued by appellant in the 
briefs. Specifically, the applied prior art makes no mention of 
first and second operating systems and of configuring management 
information for the operating system. The examiner's "finding" 
of different operating systems in Flood is nothing more than 
speculation and has no support in the reference. While we 
suspect that different devices can operate under different 
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operating systems, and that communicated information must be 
configured based on the operating system, we are not permitted to 
substitute our opinions or beliefs for evidence lacking in the 
record. The examiner is required to provide a clear evidentiary 
record to support the rejection of each claim. The prior art 
applied in the examiner's rejection simply does not provide the 
support needed to reject claims 3, 9 and 17. 

In summary, the examiner's anticipation rejection has 
been sustained with respect to all claims, and the obviousness 
rejection has been sustained with respect to claims 2, 8 and 15, 
but has not been sustained with respect to claims 3, 9 and 17. 
Therefore, the decision of the examiner rejecting claims 1-21 is 
af firmed- in-part . 
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No time period for taking any subsequent action in 
connection with this appeal may be extended under 37 CFR 
§ 1.136 (a) (1) (iv) . 



AFFIRMED- IN - PART 
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STUART S. LEV^/ 
Administrative Patent Judge 



BOARD OF PATENT 



APPEALS AND 




INTERFERENCES 



JS :hh 



14 



Appeal No. 2005-0521 
Application No. 09/436,920 



BAKER & BOTTS, LLP 

2001 ROSS AVE. 

DALLAS, TX 75201-2980 



Appendix D 
Ref. 2. 



* ■ - V 



The opinion in support of the decision being entered today was not 
written for publication and is not binding precedent of the Board. 
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ON REQUEST FOR REHEARING 
Appellant requests that we reconsider that portion of our 
decision of May 24, 2005 wherein we sustained the rejection of 
claims 1, 4-7, 10-14, 16 and 18-21 as unpatentable under 
35 U.S.C. § 102(e) and the rejection of claims 2, 8 and 15 as 



unpatentable under 35 U.S.C. § 103(a). 
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Appellant asserts that we misinterpreted the teachings o 
the Flood reference in our original decision which is grounds fo 
reversing our decision with respect to the claims noted above. 

We have reconsidered our decision of May 24, 2005 in 
light of appellant's comments in the request for rehearing, and 
we find no error therein. We, therefore, decline to make any 
changes in our prior decision for the reasons which follow. 

Appellant argues that there is no "communication link" 
between terminal 24 and processing modules 18. Appellant bases 
this argument on his position that terminal 24 and program 
execution modules 18 cannot concurrently access buses 31-33 of 
system controller 16. Thus, appellant argues that Flood never 
establishes a communication link between terminal 24 and 
processors 18. In other words, appellant's argument is 
apparently based on appellant's view that a "communication link" 
requires that the complete path from terminal 24 to processors 
18 must exist at the same time. 

We note that appellant's arguments with respect to this 
feature of the claimed invention in the briefs were based on 
whether there was a connection between terminal 24 and processors 
18. We essentially found that terminal 24 was connected to 
processors 18. We now find that the fact that data in Flood is 
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sent from terminal 24 to processors 18 is sufficient to meet the 
broadest reasonable interpretation of the term "communication 
link." Appellant had the opportunity in the briefs to argue the 
meaning of the term "communication link," but failed to do so. 
Whether the examiner and the Board properly interpreted the term 
"communication link" is a question of fact which should have been 
argued before the examiner and should be part of the record we 
are now reviewing. For purposes of this decision, and based on 
the record of prosecution, we simply find that a communication 
link exists between the terminal 24 and the processors 18 of 
Flood because information is transferred between them. 

We have carefully considered the arguments raised by 
appellant in the request for rehearing, but we can find no errors 
in our original decision. We are still of the view that the 
invention set forth in claims 1, 2, 4-8, 10-16 and 18-21 is 
unpatentable over the applied prior art. 

We have granted appellant's request to the extent that we 
have reconsidered our decision of May 24, 2005, but we deny the 
request with respect to making any changes therein. 
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No time period for taking any subsequent action in 
connection with this appeal may be extended under 37 CFR 
§ 1. 136 (a) . 



REHEARING - DENIED 
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